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The  Research  and  Technology 
Organisation  (RTO)  of  NATO 


RTO  is  the  single  focus  in  NATO  for  Defence  Research  and  Technology  activities.  Its  mission  is  to  conduct  and  promote 
co-operative  research  and  information  exchange.  The  objective  is  to  support  the  development  and  effective  use  of 
national  defence  research  and  technology  and  to  meet  the  military  needs  of  the  Alliance,  to  maintain  a  technological 
lead,  and  to  provide  advice  to  NATO  and  national  decision  makers.  The  RTO  performs  its  mission  with  the  support  of  an 
extensive  network  of  national  experts.  It  also  ensures  effective  co-ordination  with  other  NATO  bodies  involved  in  R&T 
activities. 


RTO  reports  both  to  the  Military  Committee  of  NATO  and  to  the  Conference  of  National  Armament  Directors.  It 
comprises  a  Research  and  Technology  Board  (RTB)  as  the  highest  level  of  national  representation  and  the  Research  and 
Technology  Agency  (RTA),  a  dedicated  staff  with  its  headquarters  in  Neuilly,  near  Paris,  France.  In  order  to  facilitate 
contacts  with  the  military  users  and  other  NATO  activities,  a  small  part  of  the  RTA  staff  is  located  in  NATO 
Headquarters  in  Brussels.  The  Brussels  staff  also  co-ordinates  RTO’s  co-operation  with  nations  in  Middle  and  Eastern 
Europe,  to  which  RTO  attaches  particular  importance  especially  as  working  together  in  the  field  of  research  is  one  of  the 
more  promising  areas  of  co-operation. 


The  total  spectrum  of  R&T  activities  is  covered  by  the  following  7  bodies: 
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•  SAS 

•  SCI 

•  SET 


Applied  Vehicle  Technology  Panel 
Human  Factors  and  Medicine  Panel 
Information  Systems  Technology  Panel 
NATO  Modelling  and  Simulation  Group 
Studies,  Analysis  and  Simulation  Panel 
Systems  Concepts  and  Integration  Panel 
Sensors  and  Electronics  Technology  Panel 


These  bodies  are  made  up  of  national  representatives  as  well  as  generally  recognised  ‘world  class’  scientists.  They  also 
provide  a  communication  link  to  military  users  and  other  NATO  bodies.  RTO’s  scientific  and  technological  work  is 
carried  out  by  Technical  Teams,  created  for  specific  activities  and  with  a  specific  duration.  Such  Technical  Teams  can 
organise  workshops,  symposia,  field  trials,  lecture  series  and  training  courses.  An  important  function  of  these  Technical 
Teams  is  to  ensure  the  continuity  of  the  expert  networks. 
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basis  that  will  guarantee  a  solid  base  for  the  future. 
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Recommendations  on  the  Establishment  of  a 
NATO  Simulation  Resource  Library 
(RTO  TR-051  /  MSG-012) 

Executive  Summary 

In  1998,  the  North  Atlantic  Council  (NAC)  approved  the  creation  of  a  new  organisation  tasked  with  co¬ 
ordinating  the  modelling  and  simulation  (M&S)  activities  of  the  Alliance.  This  Organisation,  known  as  the 
NATO  Modelling  and  Simulation  Group  (NMSG),  was  integrated  into  the  Research  and  Technology 
Organisation  (RTO).  The  activities  of  NMSG  are  set  out  in  an  M&S  action  plan  (MSAP)  which  was  approved 
by  the  RTO  Board.  This  document  stresses  that  the  rapid  establishment  of  a  Simulation  Resources  Library 
(SRL)  is  an  important  objective  as  a  key  enabler  for  the  NMSG. 

Thus,  to  comply  with  this  action  plan,  NMSG  decided  to  form  a  working  group  tasked  with  comparing  various 
possible  implementations  of  a  NATO  SRL  and  specifying  the  best  solution. 

The  Task  Group  (MSG-012,  TG-009)  met  5  times  (in  December  2001  and  in  February,  April,  October  and 
December  2002)  and  produced  this  resultant  report.  The  TG  was  chaired  by  the  NATO  M&S  Co-ordination 
Office  (MSCO)  and  the  following  nations  were  members: 

•  Canada, 

•  France, 

•  Germany, 

•  Norway, 

•  United  Kingdom. 

The  United  States  has  a  large  experience  in  this  activity  and  provided  valuable  information  despite  not  being  a 
formal  member  of  this  Task  Group.  The  information  that  was  provided  had  a  noticeable  influence  on  the 
practical  and  economical  aspects  of  the  recommendations  of  the  Task  Group.  Other  factors  influencing  the  TG 
conclusions  in  establishing  simulation  resources  repositories  were  the  finding  of  the  European  project  EUCLID 
RTP  11.13  “Realising  the  potential  of  networked  simulation  in  Europe”. 

The  first  chapter  of  the  final  report  describes  briefly  the  background  and  the  rationale  for  the  establishment  of  a 
NATO  SRL.  The  second  chapter  introduces  national  projects,  current  or  in  preparation.  National  requirements, 
wishes,  opinions  or  visions  are  also  expressed  in  this  chapter.  Chapter  3  analyses  requirements  and  identifies 
priority  contents  for  the  SRL.  Chapter  4  describes  and  assesses  five  possible  options  for  the  implementation  of 
a  NATO  SRL: 

•  A  fully  centralised  library, 

•  A  fully  decentralised  library, 

•  Three  variants  of  an  “hybrid”  solution. 

The  preferred  solution  is  a  SRL  distributed  between  NATO  and  nations,  sharing  a  common  framework  and 
presentation  format. 

After  the  introduction  of  the  Task  Group’s  long  term  vision,  chapter  5  proposes  a  technical  solution  for 
implementing  the  SRL  solution,  in  coherency  with  the  assessment  of  chapter  4.  This  implementation  should 
essentially  be  based  on  standard  Internet  technology  and  tools.  Security,  Population  and  Maintenance  aspects  of 
the  SRL  are  also  analysed.  Human  resources  and  funding  aspects  are  addressed  and  an  implementation  plan  is 
proposed:  If  this  proposal  is  accepted  and  sufficient  resources  are  allocated  a  NATO  SRL  could  be 
implemented  by  the  end  of  2005.  Chapter  6  summarises  the  proposals  of  the  Task  Group  and  highlights  the 
human  resourcing  and  funding  aspects. 
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Recommandations  pour  la  creation  d’une 
bibliotheque  de  moyens  de  simulation 

(RTO  TR-051  /  MSG-012) 


Synthese 


En  1998,  le  Conseil  de  l’Atlantique  Nord  (NAC)  a  approuve  la  creation  d’une  nouvelle  organisation  chargee  de 
coordonner  les  activites  de  modelisation  et  de  simulation  (M&S)  de  1’ Alliance.  Cette  organisation,  appelee  «  Le 
groupe  OTAN  sur  la  modelisation  et  la  simulation  »  (NMSG),  a  ete  integree  dans  1’ Organisation  OTAN  pour  la 
recherche  et  la  technologie  (RTO).  Les  activites  de  NMSG  sont  definies  dans  le  Plan  d’ action  M&S  (MSAP) 
approuve  par  le  Comite  OTAN  pour  la  recherche  et  la  technologie  (RTB).  Ce  document  souligne  l’importance 
de  la  constitution,  dans  les  plus  brefs  delais,  d’une  bibliotheque  sur  les  moyens  de  simulation  (SRL),  qui  est 
consideree  comme  un  outil  cle  pour  le  NMSG. 

Ainsi,  afin  de  se  conformer  aux  indications  de  ce  plan  d’ action,  le  NMSG  a  decide  de  creer  un  groupe  de  travail 
ayant  pour  objectif  de  comparer  les  differentes  possibilites  de  mise  en  oeuvre  d’une  SRL  OTAN,  et  de  proposer 
la  meilleure  solution. 

Le  groupe  de  travail  (MSG-012,  TG-009)  s’est  reuni  5  fois  (en  decembre  2001  et  en  fevrier,  en  avril,  en  octobre 
et  en  decembre  2002)  et  a  redige  le  rapport  TR-51.  Ce  groupe  de  travail  a  ete  preside  par  le  Bureau  de 
coordination  des  activites  M&S  de  l’OTAN  (MSCO).  Les  pays  membres  suivants  y  ont  participe  : 

•  le  Canada 

•  la  Prance 

•  l’Allemagne 

•  la  Norvege 

•  le  Royaume-Uni 

Les  Etats-Unis  ont  acquis  une  grande  experience  dans  ce  domaine  et  malgre  le  fait  que  ce  pays  n’etait  pas 
membre  officiel  du  groupe  de  travail,  il  lui  a  fourni  des  informations  tres  utiles.  Ces  informations  ont  influence 
de  fa^on  considerable  les  aspects  pratiques  et  economiques  des  recommandations  faites  par  le  groupe  de  travail. 
Parmi  les  autres  facteurs  ayant  pu  avoir  une  influence  sur  les  conclusions  du  groupe  de  travail  en  ce  qui 
concerne  les  sources  d’ informations  sur  la  simulation,  il  y  a  lieu  de  citer  les  conclusions  du  projet  europeen 
EUCLID  RTP  1 1.13  sur  «  La  realisation  des  possibilites  de  la  simulation  distribute  en  Europe  ». 

Le  premier  chapitre  du  rapport  final  presente  l’historique  du  projet  et  fournit  la  justification  de  la  creation  d’une 
SRL  OTAN.  Le  deuxieme  chapitre  donne  la  description  de  divers  projets  nationaux  en  cours  ou  en  preparation, 
et  expose  les  differents  souhaits,  avis,  opinions  et  aspirations  des  pays  membres.  Le  chapitre  trois  fait  1’ analyse 
des  besoins  et  identifie  les  elements  prioritaires  a  inclure.  Le  chapitre  4  presente  et  evalue  cinq  options 
possibles  pour  la  mise  en  oeuvre  d’un  SRL  OTAN,  a  savoir  : 

•  une  bibliotheque  entierement  centralisee 

•  une  bibliotheque  entierement  decentralisee 

•  trois  variantes  d’une  solution  «  hybride  » 

La  solution  de  choix  consisterait  en  une  SRL  repartie  entre  l’OTAN  et  ses  pays  membres,  avec  un  cadre  et  un 
format  de  presentation  communs. 

Apres  la  presentation  de  la  vision  a  long  terme  du  groupe  de  travail,  le  chapitre  5  propose  une  solution 
technique  permettant  la  mise  en  oeuvre  du  SRL  en  conformite  avec  1’ evaluation  faite  au  chapitre  4.  En  principe, 
cette  mise  en  oeuvre  ne  devrait  faire  appel  qu’a  des  technologies  et  qu’a  des  outils  d’lnternet.  Les  aspects 
securite,  contenu  et  maintenance  du  SRL  sont  egalement  analyses.  Les  ressources  humaines  et  le  financement 
sont  examines  et  un  projet  de  mise  en  oeuvre  est  propose.  Dans  le  cas  ou  ce  projet  serait  accepte  et  ou  des 
moyens  suffisants  seraient  affectes  a  l’activite,  un  SRL  OTAN  pourrait  etre  mis  en  place  avant  fin  2005.  Enfin, 
le  chapitre  6  resume  les  propositions  formulees  par  le  groupe  de  travail,  en  soulignant  les  aspects  ressources 
humaines  et  financement. 
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Chapter  1  -  INTRODUCTION 


1.1  ORIGIN  OF  THE  TECHNICAL  ACTIVITY 

1.1.1  The  NATO  Modelling  &  Simulation  (M&S)  Organisation 

In  1996  a  temporary  NATO  working  group  was  set-up  to  assess  the  possibility  of  establishing  a  permanent 
M&S  organisation  within  the  Alliance.  This  working  group  was  named  the  Steering  Group  for  M&S 
(SGMS)  and  reported  to  both  the  Conference  of  National  Armament  Directors  (CNAD)  and  the  Military 
Committee  (MC),  via  the  Research  and  Technology  Organisation  (RTO). 

In  1998,  the  SGMS  published  two  documents:  a  final  report  proposing  a  NATO  M&S  organisation  and  a 
NATO  M&S  Master  Plan  (MSMP).  Both  documents  were  approved  by  first  the  above-mentioned 
hierarchy  (RTO,  CNAD  and  MC)  finally  by  the  North  Atlantic  Council  (NAC)  in  November  1998.  Since 
then  the  M&S  organisation  has  been  set  up  under  the  auspices  of  the  RTO,  as  shown  on  the  following 
drawing. 


Figure  1:  NATO  M&S  Organisation 

This  new  organisation  was  actually  set-up  by  the  end  of  2000  and  the  NATO  M&S  Group  (NMSG) 
established  its  first  programme  of  work  in  2000.  This  programme  of  work  was  guided  by  a  new  document 
summarising  the  MSMP  and  called  the  M&S  Action  Plan  (MSAP).  The  MSAP  recognises  the  MSMP 
objectives  as  the  leading  objectives  for  NATO  M&S  activity. 
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1.1.2  The  NATO  M&S  Action  Plan  Related  Objectives 

The  five  NATO  MSAP  objectives  are. 


Table  1:  M&S  Action  Plan  Objectives 


Objective  1 

Objective  2 

Objective  3 

Objective  4 

Objective  5 

Establish  a 
Common 
Technical 
Framework 

Provide 
Common 
Services  in 
NATO  M&S 

Develop 

Simulations 

Employ 

Simulations 

Incorporate 

Technological 

Advances 

1.1  Adopt  HLA1 

2.1  Compile 
M&S 

Information 

3.1  Identify  & 
Prioritise 
Requirements 

4.1  Plan 
Employment 

5.1  Monitor 
M&S  Related 
Advances 

1.2  Establish 

Data  Interchange 
Standards 

2.2  Provide 
M&S  Education 

3.2  Identify 
Strategies 

4.2  Provide 
Resources 

5.2  Conduct 
R&D2 

2.3  Establish  a 
Simulation 
Resource 
Library 

3.3  Allocate 
Resources 

4.3  Provide 
Databases 

5.3  Share 
Information 

2.4  Establish  a 
Help  Desk 

3.4  Execute 
Strategy 

4.4  Operate 
Simulations 

5.4  Implement 
Advances 

3.5  Provide 
feedback 

4.5  Conduct 
Impact 
Assessment 

As  can  be  seen  in  the  objective  tables,  the  establishment  of  a  Simulation  Resources  Library  (SRL)  is 
contained  within  objective  2  (sub-objective  2.3).  The  top-level  objective  2  is  the  establishment  of  a  set  of 
services,  which  should  be  provided  to  the  Alliance  for  the  future  development  and  use  of  models  and 
simulation.  Sub-objective  2.3  clearly  relates  to  the  establishment  of  a  simulation  resources  library  but 
some  other  sub-objectives  are  more  or  less  closely  linked  to  this  activity  such  as:  1.1,  2.1,  2.4,  3.5,  4.5  and 
5.3.  These  objectives  will  be  more  deeply  discussed  later  in  paragraph  3.1. 

1.2  MAIN  DEFINITIONS:  LIBRARY,  REPOSITORY  AND  CATALOGUE 

According  to  the  Harrap’s  Webster  thesaurus  (2000  edition)  there  is  little  difference  between  a  “library” 
and  a  “repository”: 

•  A  Library  is  defined  as  “A  collection  of  books,  films,  records,  etc.,  [...]  a  collection  of  programs 
that  can  be  accessed  by  a  computer  programmer  when  required”. 

•  A  Repository  is  defined  as  “A  place  or  a  container  where  things  may  be  stored  especially  a 
museum  or  warehouse  [...],  a  trusted  person  to  whom  one  can  confide  secrets!” 


1  HLA  stands  for  the  “High  Level  Architecture”  the  US  DoD  1.3  and  IEEE  1516  interoperability  standards. 

2  R&D:  Research  and  Development 
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It  seems  that  the  concept  of  a  library  suggests  some  organisational  and  administrative  capability:  collected 
items  should  be  classified  in  categories  and  can  be  accessed  easily  when  needed.  In  the  repository 
definition  this  notion  of  accessibility  seems  absent,  the  capability  of  storage  is  emphasised.  It  does  not 
seem  that  existing  dictionaries  give  the  current  meaning  of  a  repository  in  reference  to  a  SRL.  Therefore  it 
should  be  noted  that  a  repository  should  inspire  confidence  in  the  usability  of  its  contents. 

Another  word,  which  could  be  used  in  this  report,  is  “catalogue”.  It  normally  refers  to  a  list  of  ordered 
references  that  can  be  used  to  retrieve  things  to  be  acquired  by  some  process.  But  a  catalogue  is  only 
supposed  to  provide  information  on  the  referred  objects  and  does  not  enable  direct  access  to  them. 

In  this  report,  both  words  “library”  and  “repository”  are  equally  used  for  simplicity  even  if  they  are  not 
exactly  synonymous.  They  both  define  a  place  where  resources  are  identified.  In  the  best  case,  products 
can  be  directly  accessed.  When  products  are  not  directly  available  in  the  library,  some  relevant 
information  should  be  given;  a  reference  which  allow  users  to  acquire  a  better  information  about  their 
nature,  their  capability,  the  constraints  for  accessing  them  and  the  best  way  to  obtain  them  should  be 
included.  The  term  “catalogue”  will  not  be  used  since  producing  a  simple  list  of  products  without  any 
relevant  information  attached  to  them  seems  to  be  of  little  utility. 

In  any  case,  the  quality  of  products  referenced  in  a  library  and  the  confidence  that  users  can  have  in  them 
should  be  a  prerequisite  before  populating  the  library. 


1.3  RATIONALE  FOR  DEVELOPING  A  NATO  SRL 

As  can  be  seen  in  Chapter  2  of  this  report,  many  nations’  M&S  organisations  have  already  established  or 
have  projects  to  create  a  Simulation  Resource  Library  (SRL).  This  emphasises  that  everybody  is 
convinced  that  an  SRL  is  the  fundamental  tool  for  monitoring  and  co-ordinating  the  development  of  M&S 
in  a  structured  organisation.  It  is  not  surprising  that  the  NATO  MSAP  clearly  identifies  the  establishment 
of  an  SRL  as  an  important  objective.  The  high-level  funding  objective  of  the  MSAP  and  the  NATO 
supporting  M&S  organisation  is  to  promote  interoperability  and  reuse  of  M&S.  Reuse  is  not  possible 
without  a  specific  knowledge  of  available  M&S  assets. 

More  specifically  the  MSAP  Sub-objective  2.3  documents  that  the  “NATO  Simulation  Resource 
Library”  (NSRL),  is  a  fundamental  tool  to  promote  interoperability  and  the  sharing  of  M&S  resources 
amongst  Alliance  Nations.  In  2000  the  NATO  MSG-012  Task  Group  009  was  established  for  fulfilling 
this  objective. 


1.4  DESCRIPTION  OF  THE  TECHNICAL  ACTIVITY 

This  technical  activity  was  undertaken  under  the  hospices  of  the  NMSG  in  accordance  with  the  RTO 
procedures  governing  the  RTO  technical  team  activities.  The  terms  of  reference  (TOR)  of  this  SRL 
technical  activity  asked  for  “improving  the  cost-effectiveness  of  NATO  modelling  and  simulation  (M&S) 
by  satisfying  common  requirements  by  a  common  means”.  The  Task  Group  (TG)  TOR  document 
explicitly  refers  to  the  NATO  M&S  Action  Plan  Sub-objective  2.3,  “Promote  the  sharing  of  M&S 
resources  through  a  simulation  resource  library  (SRLf\ 

The  TOR  recommend  that  “NATO  establish  an  SRL,  automated  if  possible,  to  promote  the  sharing  of 
M&S  resources  efficiently  and  cost-effectively  across  the  Alliance.  This  effort  managed  by  the  Modelling 
and  Simulation  Co-ordination  Office  (MSCO)  relied  initially  on  national  contributions”. 
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The  initial  objectives  of  this  technical  activity  were  to: 

•  Identify  the  types  of  resources  to  be  shared  among  the  Alliance, 

•  Perform  an  investment  appraisal/benefit  analysis  for  the  SRL  as  a  prelude  to  obtaining  central 
NATO  funding  for  SRL. 

Based  on  these  terms  of  reference,  the  task  group  proposed  a  possible  short-term  implementation  for  a 
future  NATO  SRL,  taking  into  account  the  budget  constraints  and  human  resources  as  they  are  currently 
available  within  NATO  and  member  nations.  A  vision  of  the  future  SRL  was  developed  as  a  starting  point 
to  propose  a  technical  implementation  that  will  be  capable  of  future  improvements  in  respect  to  what  can 
be  envisaged  for  the  mid  and  long-term  technology  evolution. 


1.5  TASK  GROUP  PARTICIPATION  AND  ORGANISATION 

Participating  nations  were: 

•  Canada, 

•  France, 

•  Germany, 

•  Norway, 

•  UK. 

The  US  M&S  Resources  Repository  (MSRR)  was  explicitly  named  as  the  referent  example  of  an  actual 
implementation  of  SRL.  Unfortunately  it  was  not  possible  for  this  nation  to  participate  in  the  TG. 
Nevertheless  the  US  NMSG  delegation  provided  information  required  to  the  group. 

The  group  had  5  working  meetings  rotating  between  nations.  The  Internet  capability  was  also  extensively 
used  to  support  the  TG  work. 

Due  to  the  short  time  allocated  to  the  group,  drafting  the  final  report  was  the  leading  activity. 

Chapter  2  of  the  report  provides  national  input:  describing  current  and  future  national  projects,  wishes  and 
hopes  of  nations  for  a  NATO  SRL.  Chapter  3  is  the  evaluation  of  SRL  requirements  from  a  NATO  and  a 
more  general  perspective.  Chapter  4  discusses  possible  implementations  (distributed  versus  centralised 
solutions).  Chapter  5  elaborates  on  a  preferred  solution  taking  into  account  various  implementation 
constraints,  security,  costs  and  human  resources  issues.  Chapter  6  discusses  main  conclusions  and 
recommendations  to  be  provided  to  NATO  and  national  authorities. 
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REQUIREMENTS 


2.1  CANADA 

As  the  UK  (see  paragraph  2.5),  Canada  adopted  the  concept  of  “Synthetic  Environment”.  For  Canada, 
a  Synthetic  Environment  (SE)  is  a  “computer  linkage  of  models ,  simulations ,  people  (real  or  simulated ), 
and  equipment  (real  or  simulated)  into  a  common  representation  of  the  world 

Within  the  Canadian  Department  of  National  Defence  (DND),  the  focal  point  for  information  on  M&S  and 
SE  is  the  “SE  Co-ordination  Office”  (SECO). 

The  present  situation  in  the  Department  of  National  Defence  (DND)  and  the  Canadian  Forces  (CF)  is 
rather  difficult  in  relation  to  M&S/SE  (Modelling  &  Simulation  and  Synthetic  Environment):  DND  has  no 
common  M&S/SE  database,  no  common  repository,  no  common  Resource  Centre,  no  common  SE,  no 
common  SE  Development  Environment  or  no  common  library.  However,  there  is  one  M&S  Catalogue 
(http://www.drdc-rddc.gc.ca/SECO/msrr  e.html).  It  has  helped  tremendously  in  the  recent  past  to  increase 
the  awareness  about  M&S/SE  in  DND  /CF.  It  was  not  designed  for  and  was  not  able  to  push  the  yardstick 
with  respect  to  enhancing  interoperability  since  no  assets  were  present  in  the  first  place  thus  no  assets 
could  be  shared.  However,  if  DND/CF  want  to  make  significant  improvements  in  better  system  designs, 
faster  acquisition  schedules  or  cheaper  total  costs,  the  Catalogue  has  helped  in  focusing  attention  on  the 
requirement  to  perform  much  more  integrated  activities  in  Concept  Development  and  Experimentation 
(CDE),  Material  Acquisition  and  Support  (MA&S),  Training,  Mission  Rehearsal  using  M&S  tools  that  are 
interoperable,  common  and  reusable.  This  Catalogue  has  helped  in  crystallising  the  requirement  for 
commonly  shared  assets,  common  use  tools,  common  database,  common  SEs,  particularly  since  Canada, 
like  the  US  and  NATO,  has  also  adopted  the  HLA  architecture.  Without  a  repository  of  one  or  more  likely 
several  nodes  in  the  country,  it  is  clear  that  DND/CF  will  not  be  in  a  position  to  realise  the  potential  of 
networked  simulations.  It  would  be  a  significant  shortfall  as  a  Distributed  Mission  Training  capability  for 
instance  is  starting  to  be  required  to  be  interoperable  with  our  neighbours  to  the  South.  A  Table  describing 
the  present  catalogue  entry  template  is  shown  in  Annex  A. 

In  addition  to  a  larger  catalogue  of  assets,  DND/CF  will  require  a  large  Repository  of  assets.  Indeed, 
several  project,  like  the  Canadian  Aerospace  SE  (CASE  project)  and  several  Technology  Demonstrations 
(TD)  projects  like  the  Tactical  Aviation  Mission  Simulation  System  (TAMSS  TD),  the  Maritime  Air 
Littoral  Ops  (MALO  TD),  Advanced  Distributed  Mission  Training  TD  will  all  develop  Federates, 
Federations  and  /or  related  resources  or  assets.  Other  Distributed  Simulations  efforts  are  planned  to 
participate  in  various  large  CD&E  activities  (such  as  Joint  Global  Wargaming  2004).  A  SE  Development 
Environment,  the  unclassified  Joint  Simulation  Network  (JSimNet)  and  a  classified  Experimentation 
Network,  the  Canadian  Forces  Experimentation  Network  (CFXNet,  connected  to  the  Common  Federated 
BattleLab  Net  with  the  US  and  the  NATO  Consultation,  Command  and  Control  Agency  (NC3A))  will  be 
available  to  support  these  Distributed  Simulations  efforts. 

Requirements: 

It  is  understood  that  a  lot  more  HLA/FEDEP-based1  information  than  is  currently  available  will  be 
required  to  make  greater  use  of  the  assets.  Documents  (under  various  formats  such  as  .doc  .pdf  .ppt  etc.) 
that  support,  illustrate  and  document  the  model  or  simulation  or  the  asset  ought  to  be  included  in  the 
catalogue. 


1  FEDEP  stands  for  HLA  “Federation  and  Development  Process”,  a  guide  for  developing  and  running  HLA  federations 
approved  by  both  the  US  DoD  and  IEEE  (1516.3  standard). 
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1.  It  is  also  understood  that  if  reusability  is  desired,  one  will  have  to  ensure  that  some  form  of  a 
Verification  Validation  and  Accreditation  Process  (VV&A)  process  has  been  applied  to  the  assets, 
before  they  can  be  life  cycled  and  made  available  to  the  national  community  first  in  a  user  friendly 
(not  user-hostile)  Repository  environment.  Further,  access  to  NATO  Catalogues  and  Repositories 
would  be  also  required.  In  some  cases,  either  in  internally  in  Canada  or  in  NATO,  user  fees  may 
be  required  and  may  still  be  cost  effective  both  ways:  for  Canadians  as  well  as  for  Allies. 

2.  If  one  requires  several  (repository)  nodes  in  the  same  country,  as  well  as  several  nodes  for  all  the 
participating  countries,  then  a  common  framework  and  infrastructure  for  the  repository  of  the 
common  data  will  have  to  be  tabled,  and  framed  by  the  MSG  012  task  group  along  the  lines  of 
success  stories,  like  the  EUCLID2  RTP3  11.13  (see  paragraph  2.2.3.  and  2.5.3)  to  guide 
participating  nodes  of  the  participating  countries  whenever  they  will  be  ready  to  build  their  nodes 
in  conjunction  with  their  own  SE  Development  Environments  (SEDE). 

3.  It  is  not  clear  whether  NATO  has  the  requirement,  the  resources  or  the  capacity  to  life  cycle  the 
M&S/SE  assets  of  several  countries.  However,  if  the  NATO  MSG  012  Task  Group  provides 
minimum  requirements  for  connectivity  and  if  we  suggest  recommended  tools  (software  and 
hardware)  and  best  repository  practices,  then  many  NATO  SRL  countries  could  quickly  benefit 
from  NATO  SRL  efforts. 


2.2  FRANCE 

In  order  to  understand  the  current  status  of  the  simulation  resource  library  in  the  French  Ministry  of 
Defence  (MoD),  a  short  review  of  its  General  Directorate  for  Armaments  (DGA)  organisation  for  the 
M&S  activities  is  necessary.  DGA  is  the  French  procurement  agency. 

2.2.1  Current  Status 

Within  the  DGA,  the  policy  of  M&S  and  Simulation  Based  Acquisition  (SBA)  activities  are  defined  by 
the  “Complex  System  Engineering”  Department  (SC)  of  the  Technical  Policies  and  Planning  Directorate 
(DSP).  The  policy  is  approved  on  a  yearly  basis  at  the  DGA  directorate  level.  A  Simulation  Action  Plan 
has  been  agreed  by  the  DGA  directorate  and  is  under  executive  responsibility  of  the  SC  department. 

The  technical  M&S  activities  are  mainly  carried  out  by: 

•  The  technical  centres  of  the  Systems  Evaluation  and  Test  Directorate  (DCE), 

•  The  Defence  Analysis  Centre  (CAD)  of  the  Technical  Policies  and  Planning  Directorate  (DSP). 

Technical  centres  within  the  Armed  Forces  (Land  CROSAT4,  Navy  ANPROS5,  Air  Force  CASI6)  carry 
out  the  operational  research  activities. 

There  is  no  common  simulation  resource  library  shared  at  the  MoD  level.  However,  current  initiatives  are 
set  out  below. 


2 

EUCLID  =  European  Co-operation  for  the  Long  term  In  Defence 

3  RTP=  EUCLID  Research  Technology  Project 

4  CROSAT  =  Centre  de  Recherche  Operationnelle  et  de  Simulation  de  l’Armee  de  Terre 

5  ANPROS  =  Antenne  Plan,  Recherche  Operationnelle  et  Simulation 

6  CASI  =  Cellule  d’ Analyse,  de  Simulation  et  d’Innovation 
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At  the  DGA  level,  the  simulation  resources  are  capitalised  and  managed  locally  within  each  centre.  Most 
of  the  time,  there  is  a  basic  storage  (e.g.  ASCII* 7,  Microsoft  Excel  files)  of  input/output  data,  simulation 
parameters,  results,  scenarios,  etc.  Only  few  centres  have  catalogues  or  databases  of  models  and 
simulation  tools.  Configuration  management  is  rarely  considered. 

2.2.2  National  SRL  in  Development 

2.2.2. 1  Repository  Activity  in  the  ARCOSIM  Project 

A  unified  process  is  undertaken  by  the  ARCOSIM  (Architecture  Commune  de  Simulation)8  study  whose 
purpose  is  to  specify  and  develop  a  common  simulation  infrastructure  named  “Infrastructure  Technique 
Commune  de  Simulation  (ITCS)”  for  the  simulation  based  acquisition  of  defence  systems,  promoting 
reuse  and  interoperability.  This  study  started  in  March  2001.  It  is  under  the  responsibility  of  a  newly 
created  project  team  EPSA  (Equipe  de  Projet  Simulation  pour  1’ Acquisition).  14  of  the  18  DCE’s  centres 
and  the  CAD  are  directly  involved  in  this  project.  This  large-scale  project  embodies  one  of  the  strategic 
directions  decided  by  the  Simulation  Action  Plan  approved  at  DGA  directorate  level. 

The  first  step  of  this  project  was  to  gather  general  information  and  technical  characteristics  about  the 
legacy  M&S  tools  used  in  those  centres.  The  collected  information  can  serve  as  input  data  for  a  national 
SRL.  The  present  national  vision  of  the  repository  is  quite  schematic,  there  will  be  common  databases  that 
include: 


•  Models, 

•  Simulations, 

•  Supporting  tools, 

•  Scenarios, 

•  Results, 

•  Hardware/software  configurations. 

These  databases  will  not  only  serve  as  catalogues.  The  users  will  have  access  to  the  specification 
documents  related  to  models  or  simulations;  the  source  code,  possibly  the  executable  components;  the 
scenario  files  and  the  validation  of  repository  resources,  etc.  The  issues  related  to  the  information  security 
and  the  proprietary  rights  will  also  be  investigated. 

The  specification  of  the  ITCS  functional  architecture  is  expected  by  end  2003.  A  prototype  will  be  tested 
to  validate  the  specification.  The  detailed  requirement  analysis  is  in  progress.  The  development  of  the 
ITCS  should  be  achieved  by  2005. 


2.2.2.2  Joint  Simulation  Database:  BDSIM  2000  Project 

Another  initiative  is  the  BDSIM9  2000  project.  The  CAD  is  in  charge  of  the  BDSIM  2000  project,  which 
aims  to  develop  a  joint  simulation  database  for  Joint  Staff  M&S  purposes  (tactical,  operation  and  strategic 
levels). 

This  database  is  mainly  a  catalogue  which  makes  reference  to  M&S  products  (models,  simulations)  and  to 
simulation  tools  (simulation  frameworks  and  support  environment,  scenario  preparation  tools...). 


y 

ASCII  =  American  Standard  Code  for  Information  Interchange 

8  ARCOSIM  =  Architecture  Commune  de  Simulation 

Q 

BDSIM  =  Base  de  Donnees  de  Simulation 
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The  content  of  the  BDSIM  2000  is  organised  with  respect  to  the  following  categories: 

•  Product  name  (or  acronym), 

•  Short  description  of  the  product  (one  sentence), 

•  Detailed  description  of  the  product, 

•  Simulation  type  (simulation  application,  war  game. . .), 

•  Conformity  to  current  or  past  standards  (DIS,  HLA,  SEDRIS. . .), 

•  Simulation  level  (strategic,  operation,  tactical,  weapon  system,  physical  phenomenon. . .), 

•  Operational  domain  (air,  sea,  land,  joint,  NBC,  EW. . .), 

•  Main  purpose  (operational  analysis,  acquisition,  planning  and  rehearsal,  training), 

•  Armed  forces  systems  classification  (Air,  Land,  Navy,  Planning  and  Logistics,  Projection, 

•  Deep  Strike,  Deterrence,  C3I), 

•  Current  status  (in  preparation,  in  use,  obsolete. . .), 

•  Custodian  organisation/owner, 

•  Point  Of  Contact  (POC)  name, 

•  Date  and  time  of  the  last  updated  information, 

•  Keywords. 

It  is  important  to  stress  that  associated  documentation,  such  as  model  or  simulation  descriptions,  could  be 
attached  to  the  related  categories. 

The  database  will  be  hosted  on  a  single  server  but  used  in  a  distributed  way  (defence  Intranet  or  Internet  if 
the  Intranet  is  unavailable)  since  its  utilisation  is  based  on  standard  web  technologies:  online  fielding  form 
and  secured  access  to  authorised  users  only  (online  identification,  data  encryption). 

The  BDSIM  2000  offers  the  following  services:  multi-criteria  search  engine,  data  creation  with  a 
validation  process,  notification  for  online  modification,  request  for  product  file  destruction,  automatic 
report  editing.  It  also  offers  useful  services  such  as  members’  directory  (automatically  generated  and 
updated),  discussion  forum,  links  to  other  MoD  sites.  A  more  detailed  description  of  the  BDSIM 
architecture  is  provided  in  Annex  B. 

The  development  of  this  database  started  in  November  2001.  The  prototype  version  was  delivered 
4  months  later.  The  final  version  is  due  October  2002.  Data  is  currently  under  creation  and  validation.  The 
evaluation  and  validation  of  the  BDSIM  2000  is  planned  in  early  2003. 

BDSIM  2000  will  be  open  to  the  M&S  community  within  the  French  MoD.  As  an  example,  some  of  the 
collected  information  in  the  ARCOSIM  project  will  be  inserted  into  the  BDSIM  2000. 

2.2.3  Prototype  of  a  European  Repository  in  EUCLID  11.13 

France  is  one  of  the  13  nations  involved  in  the  EUCLID  RTP  11.13  project:  “Realising  the  potential  of 
networked  simulation  in  Europe”.  As  the  UK  chairs  this  project,  a  detailed  description  is  given  in  the 
relevant  section  (see  paragraph  2.5.1). 
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2.2.4  National  Requirements  on  a  NATO  SRL 

The  French  point  of  view  about  the  requirements  on  a  NATO  SRL  is  mainly  based  on  the  experience 
drawn  from  existing  projects:  national  SRLs  (in  development)  and  EUCLID  11.13  repository 
requirements. 

Hence,  the  NATO  SRL  is  expected  to  contain  the  following  mandatory  items: 

•  Product  name  (or  acronym), 

•  Short  description  of  the  product  (one  sentence), 

•  Detailed  description  of  the  product, 

•  Simulation  type  (simulation  application,  war  game. . .), 

•  Simulation  level  (strategic,  operation,  tactical,  weapon  system,  physical  phenomenon. . .), 

•  Operational  domain  (air,  sea,  land,  joint,  NBC,  EW. . .), 

•  Main  purpose  (operational  analysis,  acquisition,  planning  and  rehearsal,  training), 

•  Current  status  (in  preparation,  in  use,  obsolete. . .), 

•  POC  name, 

•  Date  and  time  of  the  last  updated  information, 

•  Proprietary  rights  (free,  industry,  government), 

•  Current  HLA  compliance  status  (impossible,  certified,  under  test). 

In  the  best  case,  it  would  be  noticeable  to  have  an  access  to  the  following  optional  items: 

•  Description  documents  about  models  and  simulations, 

•  Models  (for  executable  software,  the  type  of  the  operating  system  and  the  compiler  version  are 
needed), 

•  Simulations  (for  executable  software,  the  type  of  the  operating  system  and  the  compiler  version 
are  needed), 

•  VV&A  information, 

•  Basic  scenario  template  if  the  models  and  the  simulations  can  be  retrieved, 

•  Keywords. 


2.3  GERMANY 

The  present  day  situation  in  the  Bundeswehr  (German  Federal  Armed  Forces)  concerning  a  simulation 
resource  library  is  best  understood  by  simply  following  the  chronological  order.  We  can  identify  basically 
3  stages. 

Stage  1  is  characterised  by  a  vast  number  of  lists  and  catalogues  that  were  produced  independently  from 
each  other  by  different  organisational  units  (OU)  of  the  Bundeswehr. 

Each  of  those  activities  was  focused  on  the  peculiarities  of  the  OU:  e.g.  there  were  lists  on  the  Operations 
Research  tools,  on  training  simulations,  on  simulations  to  support  Rapid  Prototyping.  But  there  are  also 
lists  containing  management  data,  like  cost  per  training  hour,  etc. 
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Those  lists  were  neither  exhaustive  nor  correlated  to  each  other.  Furthermore,  they  are  partially  outdated 
and  to  the  author’s  knowledge  only  one  catalogue  is  dedicated  to  the  potential  of  federated/distributed 
simulation  available  on  the  Bundeswehr  Intranet. 

That  catalogue  has  led  to  stage  2,  which  began  in  approximately  1995,  when  the  importance  of 
distributed/federated  simulation  was  recognised  in  Germany.  Hence,  this  catalogue  focused  on  the 
interfacing  capabilities  of  simulation  systems.  However,  the  knowledge  about  M&S  standards  like  HLA, 
or  DIS  was/is  not  widespread  enough  at  that  time,  to  have  the  database  completed  by  the  local  simulator 
authorities. 

Those  lessons  learned  have  finally  led  to  stage  3,  which  is,  where  we  are  now  (2002):  it  is  recognised  that 
the  vital  database  entries  have  to  reflect: 

•  a  verbal  description  of  the  simulation  (task,  purpose,  category); 

•  availability  of  the  source  code  (programming  language); 

•  support  of  Data  Interchange  Formats  (DIFs);10 

•  connection  to  an  external  database  (and  if,  underlying  data  structure/model); 

•  availability  and  quality  of  documentation; 

•  information  about  the  vendor/developer; 

•  knowledge  about  internal  interfaces  (modularity); 

•  access  to  an  API  of  the  simulation  application. 

By  reviewing,  updating  and  merging  the  current  catalogues  and  adding  the  above-mentioned  information, 
the  Bundeswehr  is  presently  on  the  way  to  gather  the  relevant  information  about  their  simulation  systems. 
The  results  are  to  be  published  in  the  Bundeswehr  Intranet. 

Although,  stage  3  is  doubtless  a  necessary  pre-condition  for  a  resource  library,  it  suffers  from  a  lack  of 
practical  relevance:  when  establishing  a  federated  simulation,  the  potential  federates  should  be 
documented  according  to  the  HLA  4603  NATO  Standardisation  Agreement  (STANAG).  Ideally, 
a  repository  will  contain  all  of  the  above  mentioned  information  plus  the  Simulation  Object  Model  (SOM) 
plus  a  link  to  the  simulation  software  (if  appropriate). 

Summarising: 

The  German  requirements  on  a  national  and  a  NATO  SRL  are: 

1 .  Establishing  a  national  data  collection  as  described  as  stage  3; 

2.  Access  to  a  NATO  data  collection  providing  similar  information  as  the  national  SRL; 

3.  Access  to  a  NATO  Simulation  Resource  Library  that  allows  for  access  to  the  data  model 
description  (as  far  as  relevant  for  a  distributed  simulation)  and  providing  a  link  either  to  the 
simulation  software  itself,  or  at  least  to  a  point  of  contact  (POC). 
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2.4  NORWAY 

In  Norway,  simulation  is  used  on  many  levels  in  the  defence  sector.  Production  simulation,  operational 
and  training  simulation  and  technical  simulation  of  new  weapon  systems  are  some  examples.  For  instance, 
when  new  concepts  for  officer  training  are  chosen,  simulation  plays  an  integral  part  of  the  analysis  effort. 
Similarly,  long-term  costs  are  simulated  when  choosing  among  future  force  structures.  At  the  other  end  of 
the  spectrum,  new  C3I11  solutions  for  ship-to-ship  missiles  also  rely  heavily  upon  such  SE.  Simulations 
reside  in  industry,  within  operational  and  training  units  as  well  as  in  the  research  establishments. 

There  presently  exists  no  common  database,  repository  or  library  that  enables  an  overview  of  the  plethora 
of  simulation  models  used  by  different  agencies  of  the  Norwegian  Armed  Forces.  However,  at  the 
Norwegian  Defence  Research  Establishment  (FFI)  a  model  library  has  been  established  for  the  use  of  its 
defence  analysts,  mostly  in  support  of  long  term  defence  planning.  The  library’s  models  are  mainly 
focused  on  operational  and  force  production  aspects.  The  library  contains  information  relating  to  key 
aspects  of  each  simulation  model,  including  the  model  documentation  and  POCs.  At  present,  the  model 
library  is  a  text-only  overview  of  the  different  models,  based  on  queries  sent  to  POCs  for  each  model. 
POC  is  defined  as  “the  person  with  most  knowledge  of  the  model”.  The  query  process  is  quasi-y early  and 
consists  of  all  POCs  being  asked  to  verify  existing  information  -  and  all  project  leaders  to  provide 
documentation  on  new  models.  The  results  from  the  queries  are  presented  on  an  internal  web-site  in 
HyperText  Mark-up  Language  (HTML). 

The  model  library  contains  data  in  the  following  format  (the  list  is  not  exhaustive): 

•  Model  name, 

•  Purpose  of  model, 

•  Joint/ Army/Navy/Air/Logistics,  etc. , 

•  Strategic  level,  operational  level,  tactical  level,  weapon  systems  level, 

•  Different  versions, 

•  Programmers/developers, 

•  Year  finished  and  year  of  last  updated  information, 

•  Current  and  previous  projects  using  it,  current  POCs, 

•  Operating  system, 

•  Programming  language, 

•  Documentation, 

•  Comments  on  possibilities  of  re-programming/further  development  (including  plan  to  make  HLA 
compliant  if  any), 

•  Other  models  using  output  from  the  described  model, 

•  Other  models  needed  to  give  input  to  the  described  model. 

Norway  is  a  partner  in  EUCLID  RTP  11.13  and  stands  behind  the  requirements  developed  in  that  effort. 
It  is  the  Norwegian  view  that  the  NATO  SRL  only  requires  a  small  subset  of  EUCLID  11.13  to  be 
fulfilled.  As  a  minimum,  the  information  in  the  FFI  model  database  (see  above)  must  be  available  in  the 
NATO  SRL. 


11  C3I  stands  for  Command  Control  Communications  and  Intelligence. 
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2.5  UNITED  KINGDOM 

The  UK  has  a  number  of  initiatives  examining  the  sharing  of  SE,  modelling  and  simulation  assets,  the 
ability  to  interoperate  and  the  creation  of  resource  directories  or  repositories. 

The  working  UK  definition  of  an  SE  is  ‘A  computer  based  representation  of  the  real  world,  usually  a 
current  or  future  battle  space,  within  which  any  combination  of  ‘players’  may  interact.  The  players  may  be 
computer  models,  simulations,  people  or  instrumented  real  equipment’.  As  part  of  the  Infrastructure  and 
Services  initiative  the  UK  Synthetic  Environment  Co-ordination  Office  (SECO),  is  carrying  out  a  project 
to  improve  the  availability,  value  and  economy  of  SE  Assets  within  the  Ministry  of  Defence  (MoD). 
Project  SAVE  will  look  at  the  sharing  of  SE  and  simulation  assets. 

a)  The  UK  MoD  research  community  has  a  database  of  models. 

b)  The  UK  chairs  EUCLID  RTP  11.13,  ‘Realising  the  potential  of  networked  simulation  in  Europe’. 
Further  information  on  these  initiatives  is  set  out  below. 

2.5.1  Project  SAVE 

Project  SAVE  is  an  initiative  to  promote  Synthetic  Environment  Availability  and  Economy.  The  original 
objective  was  to  identify  the  requirement  for  and  options  to  deliver  a  common  set  of  SE  components  to 
UK  MoD  users.  The  first  major  part  of  the  project  was  a  stakeholder  survey  to  determine  the  current  SE 
and  simulation  assets  held  across  MoD,  the  commonality  and  overlap  of  existing  components  and  capture 
any  best  practice  in  the  sharing  of  components.  The  survey  addressed  Interoperability,  Ownership, 
Intellectual  Property  Rights  (IPR)  and  User  Rights  and  the  current  and  future  aspirations  for  sharing  SE 
components  within  the  UK  MoD  and  elsewhere.  At  the  beginning  of  the  project  UK  SECO  did  not  have  a 
comprehensive  list  of  SE,  modelling  and  simulation  assets. 

The  stakeholder  survey  will  be  carried  out  in  a  number  of  stages;  currently  it  has  created  a  simple  database 
of  in  service  training  simulation  assets.  As  the  survey  continues  it  will  identify  assets  from  research 
projects,  academia,  synthetic  environment  based  acquisition  projects  etc.  The  aspiration  is  that  this 
information  [obtained  through  the  stakeholder  survey]  will  serve  as  the  baseline  data  set  for  population  of 
any  future  national  or  international  SE  and  simulation  repositories.  It  should  be  noted  that  the  stakeholder 
survey  confirmed  that  Intellectual  Property  Rights,  MoD  use  and  re-user  rights  will  be  significant  factors 
in  the  consideration  of  sharing  SE  components. 

2.5.2  The  Defence  Scientific  and  Technology  Laboratory  (Dstl)/QinetiQ  Models  Database 

2.5.2. 1  The  DERA  Public  Private  Partnership 

In  July  2001,  under  a  public  private  partnership  arrangement  the  UK  MoD  scientific  research  base,  the 
Defence  Evaluation  and  Research  Agency  (DERA)  was  split  into  two  distinct  organisations:  QinetiQ  and 
the  Defence  Scientific  and  Technology  Laboratory  (Dstl).  Whilst  QinetiQ  is  a  commercial  company,  Dstl 
remains  an  integral  part  of  the  UK  MoD. 

The  previous  DERA  models  database  contains  approximately  800  models,  of  which  probably  more  than 
half  have  since  been  vested  in  QinetiQ  The  database  does  not  contain  information  at  component  level  -  it 
is  designed  as  a  catalogue  rather  than  a  repository.  The  quantity  and  quality  of  information  is  variable. 
A  number  of  the  models  held  are  now  obsolete.  A  review  of  the  information  held  is  currently  underway. 
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2.5.2.2  Industry  Assets 

Alenia  Marconi  Systems  (AMS),  BAE  Systems  and  Matra  BAe  have  established  a  SE  Advanced 
Technology  Group  (SE-ATG).  It  is  hoped  that  UK  MoD  will  have  visibility  of  their  SE  Assets  Repository. 

2.5.3  EUCLID  RTP  11.13 

The  UK  chairs  the  EUCLID  RTP  11.13  programme  ‘Realising  the  potential  of  networked  simulation  in 
Europe’.  This  is  a  jointly  funded  activity  involving  both  national  MODs  and  Industrial  Entities  (IEs) 
across  Europe.  The  lead  industrial  entity  (i.e.  prime  contractor)  is  Thales  Training  &  Simulation  (TT&S) 
and  the  overall  project  consists  of  23  European  companies  across  13  Nations.  The  programme  started  in 
November  2000  and  will  finish  in  October  2003,  with  a  final  demonstration  scheduled  for  November 
2003. 

The  aim  of  the  project  is  to  “overcome  the  obstacles  that  prevent  SEs  being  exploited  in  Europe”  by 
developing  a  process  and  an  integrated  set  of  prototype  tools,  which  will  reduce  the  cost  and  time-scale  of 
specifying,  creating  and  utilising  SEs  for  collective  training,  mission  rehearsal  and  simulation  based 
acquisition”. 

An  essential  part  of  this  programme  is  the  characterisation  of  assets  and  the  development  of  prototype 
repository  architecture  software  that  aims  to  provide  a  repository  server  based  solution,  independent  of  any 
COTS  software  products,  e.g.  ORACLE  DBMS.  This  will  be  used  to  develop  a  prototype  ‘pan  European’ 
Repository  that  will  store  all  information  relative  to  building  and  utilising  SEs. 

The  EUCLID  RTP  11.13  Management  Group  (MG)  has  agreed  that  those  deliverables  relevant  to  the 
repository  architecture,  including  “asset”  characterisation,  can  be  shared  with  NATO  MSG-012  TG  009. 
The  word  “asset”  is  used  in  the  RTP  1 1.13  to  represent  any  information  item  or  resources  such  as  models, 
simulations,  tools,  databases,  etc.  which  are  of  interest  for  designing,  developing  or  exploiting  SE 
modelling  and  simulations.  In  relation  to  this  report,  NATO  Simulation  Resource  Library,  the  word 
“Asset”  is  interchangeable  with  “Resource”. 


2.5.3. 1  Repository  Architecture  Requirements 

The  prime  function  of  the  repository  software  is  to  provide  a  mechanism  for  storing  and  transferring  data 
between  the  different  phases  of  the  EUCLID  RTP  11.13  SE  development  process.  Therefore  the  repository 
has  to  be  flexible,  scaleable,  distributed  and  content  specific.  The  latter  meaning  that  the  repository  will 
contain  information  about  a  variety  of  assets  that  can  be  used  in  the  design  of  an  SE  including 
documentation,  information  on  entities,  simulations,  and  previously  constructed  federations. 

The  repository  software  will: 

•  Support  the  EUCLID  11.13  SEDEP12  by  enabling  the  tools  that  support  the  SEDEP  to  access  and 
manipulate  information, 

•  Support  the  implementation  of  a  set  of  local  repository  databases  across  Europe  which  can  be 
linked  together  using  standard  networking  technology, 

•  Provide  the  ability  to  be  configurable  so  that  the  data  can  be  split  into  private  and  public  areas, 

•  Support  a  single  point  of  access  using  tools  that  support  the  SEDEP, 

•  Be  independent  of  any  vendor  operating  system  and  Data  Base  Management  Systems, 

•  Support  control  of  the  content  so  that  it  remains  with  the  owner  of  the  local  repository, 


12 

SEDEP  =  SE  Development  and  Execution  Process  which  should  be  considered  as  a  specialisation  of  or  an  extension  to  the 
HLA  FEDEP  (Federation  Development  and  Execution  Process). 
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•  Allow  for  annotation  so  that  owners  of  assets  can  add  additional  text  in  a  repository  Entry, 

•  Provide  an  access  interface  so  that  tools  developed  during  the  Euclid  11.13  project  or  COTS  tools 
can  access  it, 

•  Provide  off-line  capabilities,  to  allow  tools  supporting  the  SEDEP  to  run  off-line  (i.e.  without 
connection  to  the  repository), 

•  Scaleable,  so  that  there  is  no  limit  as  to  how  much  data  is  stored, 

•  Not  restrict  the  type  and  size  of  an  Entry, 

•  Provide  easy  maintenance  of  entries  by  ensuring  that  the  software  helps  the  users  modify  or 
remove  information  from  the  database. 


2.5.3.2  Data  Storage 

The  repository  may  contain  types  of  data  such  as: 

•  Information  about  SE  assets  that  could  be  used  in  an  SE  (e.g.  simulators,  simulations,  etc.), 

•  Information  about  databases  (visual,  natural  environment,  etc.) 

•  Information  about  support  tools  (Input  Output  Systems  (IOS),  data  loggers,  stealth  viewers,  User 
Requirements  tools,  SE  development  tools,  Execution  Management,  etc) 

•  Federation  definition  and  development  materials,  tested  Federations 

•  Project  parameters  (cost,  time,  schedule  etc.) 

•  Executable  code  (or  links  to  executable  code)  that  can  be  downloaded  and  run  during  the 
execution  phase  of  the  process, 

•  Data  components  for  the  requirements,  design,  execution  and  results  for  a  particular  SE 
experiment. 

2.5.3.3  Repository  Usage 

The  repository  can  be  used  at  a  number  of  different  levels: 

Individual  libraries  (Usage  1) 

In  its  simplest  form,  users  can  adopt  the  Database  and  Characterisation  of  assets  structure  to  store 
information  on  their  assets  (e.g.  simulators,  simulations,  stealth  viewers,  data  loggers  etc.)  to  build  their 
own  library. 

SE  construction  (Usage  2) 

The  repository  can  support  the  construction  and  execution  of  an  SE  as  an  internal  project.  In  this  form  of 
usage,  the  repository  is  part  of  the  user  Intranet  that  is  protected  by  its  own  firewall.  Examples  1  and  2  of 
repository  usage  are  shown  in  the  Figure  2.  The  private  repository  isolated  from  the  network  by  an  ‘air 
gap’  ensures  that  individual  access  rights  and  IPR  are  controlled  by  the  user. 

Internet  visualisation  of  other  organisations’  assets  (Usage  3) 

In  this  the  public  Internet  is  used  to  connect  many  local  repositories.  If  requested,  the  owner  of  the  assets 
could  either  licence  the  asset  to  another  organisation  or  run  it  remotely  at  their  own  site. 

SE  consortia  (Usage  4) 

An  SE  user  can  participate  in  an  SE  project  as  part  of  a  consortium.  In  this  case  the  participants’ 
repositories  are  connected  to  an  “Internet  type”  network.  This  is  a  more  complex  usage  of  the  repository 
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where  companies  will  want  to  protect  their  IPR  and  military  sensitive  information  from  either  competing 
companies  or  potential  hackers. 


Private  library 
of 

SE  assets 


Public 
library  of  SE 
assets 


Shared 

SE 
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Figure  2:  EUCLID  RTP  11.13  Repository  Usage 


2.5.4  UK  Requirements 

The  UK  requires  that  the  NATO  SRL  should  be  a  linked  set  of  Simulation/SE  repositories  or  libraries.  The 
EUCLID  11.13  repository  could  be  a  node  on  the  NATO  SRL.  In  addition,  the  EUCLID  11.13  methods 
for  asset  characterisation  including  the  repository  architecture  software  could  provide  a  basis  for 
developing  NATO  SRL  and  National  SRL  nodes.  In  terms  of  access  to  information  on  Simulation  and  SE 
assets,  as  a  minimum,  top  level  information  on  the  assets  and  relevant  points  of  contact  details  should  be 
available  to  all  NATO  participants.  The  information  should  be  organised  to  allow  information  to  be 
abstracted  to  the  requirements  of  a  variety  of  user  types. 


2.6  THE  UNITED  STATES  MSRR 

The  MSG  012  task  group  members  drafted  this  section  according  to  information  provided  by  the  US 
Department  of  Defense  (DoD)  Defense  M&S  Office  (DMSO).  The  task  group  established  a  questionnaire 
during  its  second  meeting,  sent  it  to  the  US  and  received  a  detailed  answer. 

The  US  “Modeling  and  Simulations  Resource  Library”  (MSRR)  was  established  in  the  mid-90’  as  a  DoD- 
level  effort.  It  is  a  fully  distributed  repository  with  a  central  node  operated  by  the  US  DoD  M&S 
Information  Analysis  Centre  (MSIAC)  under  the  leadership  of  DMSO.  In  fact,  there  are  multiple 
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“MSRRs”:  DMSO,  each  Service,  and  the  Missile  Defense  Agency  (MDA)  operate  independent  systems, 
which  can  conduct  mutual  searches  of  each  other.  While  content  is  intended  to  be  exclusive,  in  practice 
there  are  exceptions. 

2.6.1  Access  Conditions 

In  the  MSRR  there  is  a  public  part  that  can  be  accessed  by  everybody  via  the  Internet  and  a  private  part. 
This  private  part  is  not  accessible  by  non-US  citizens.  Account  holders  for  the  DMSO  MSRR  must  be 
U.S.  citizens,  active  duty  military  or  civilian  employees  of  the  U.S.  Department  of  Defense.  Contractors 
under  current  contract  to  the  U.S.  DoD  may  also  receive  accounts. 

The  current  number  of  account  holders  in  the  DMSO  MSRR  was  1549  in  mid-2002.  Searches  (not  web 
hits)  conducted  on  the  DMSO  MSRR  varied  between  928  and  1453  per  month. 

2.6.2  MSRR  Contents  and  their  Origin 

Most  resources  are  only  catalogued,  however,  the  system  can  and  does  contain  resources,  which  can  be 
distributed  to  users. 

Typical  resources  that  can  be  found  in  the  US  MSRR  are: 

•  Functional  descriptions  of  the  Mission  Space, 

•  Data  Interchange  Formats, 

•  Data  sources, 

•  Databases, 

•  Documentation, 

•  High  Level  Architecture  documentation, 

•  High  Level  Architecture  Federation  Object  Models  (FOMs), 

•  High  Level  Architecture  Simulation  Object  Models  (SOMs), 

•  Lessons  leamed/successful  practices, 

•  Models, 

•  Points  of  Contact, 

•  Simulations, 

•  Subject  Matter  Experts, 

•  Tools  and  utilities. 

In  addition  some  sites  can  provide  additional  types  of  information  on  : 

•  Facilities, 

•  Organisations, 

•  Related  Sites, 

•  Simulators, 

•  Studies, 

•  Technology  Research. 
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The  sources  of  information  are  too  numerous  to  list. 

About  mid-2002  there  were  1333  different  resources  items  in  the  DMSO  MSRR. 

2.6.3  Ownership,  Property,  Rights  on  available  Tools,  Models,  Algorithms 

Ownership  rights  vary.  All  DoD  owned  or  funded  software  is  subject  to  DoD  distribution  restrictions; 
distribution  restrictions  may  also  apply  to  information  about  the  resources.  The  MSRR  supports 
enforcement  of  these  restrictions.  The  commercial  resources  are  governed  by  copyright.  Information  on 
how  to  obtain  resources  and  any  use  restrictions  are  available  for  all  resources.  At  this  time,  the  MSRR 
does  not  distribute  any  item  that  is  commercially  owned. 

Entries  are  validated,  however,  the  nature  of  the  validation  varies.  Some  systems  automatically  validate 
URLs13,  others  check  resource  related  web  pages  for  changes.  The  DMSO  MSRR  also  validates  resources 
manually,  on  a  cyclical  basis,  as  this  is  the  only  way  to  validate  content.  Unfortunately,  it  is  labour 
intensive.  Upgraded  MSRR  software  will  partially  automate  this  by  generating  e-mails  to  sponsor  and 
technical  points  of  contact  on  a  cyclical  basis. 

2.6.4  Implementation 

The  Service  sites  use  nearly  identical  software  but  each  Service  has  different  management  methods. 

The  front  end  is  written  entirely  in  JAVA;  the  authentication  system  is  mostly  in  C.  The  back  end  is  an 
Oracle  database.  All  Services  can  use  different  commercial  software.  The  current  system  is  running  on 
Microsoft  Windows  based  platforms,  however  as  most  of  the  system  is  server  side  JAVA  it  would  port  to 
other  platforms. 

The  system  relies  on  certain  security  features  within  the  Oracle  database. 

2.6.5  Cost  Aspects 

All  the  MSRR  systems  have  gone  through  multiple  software  releases  over  the  course  of  six  years.  Given 
that,  the  overall  cost  of  development  is  more  than  $2.5  million  (U.S.),  but  difficult  to  pin  down. 

The  annual  cost  of  software  maintenance  is  dependent  on  the  extent  of  modifications  required.  DMSO 
found  through  system  use  that  significant  improvements  were  necessary.  Additionally,  new  COTS 
software  releases,  required  modifications  to  the  MSRR  code.  The  workload  justifies  1-2  people.  The 
system  operates  on  two  Windows  compatible  servers,  one  hosting  the  database,  and  the  other  the  front 
end.  Hardware  costs  would  vary,  depending  on  the  server  capability. 

There  is  no  cost  sharing  between  DoD  nodes;  each  node  is  fully  independent. 

2.6.6  Human  Resources 

The  DMSO  node  requires  about  1/2  staff-year  for  resource  administration,  and  about  1/4  staff  year  or  less 
for  software  systems  administration.  This  assumes  that  the  resource  administrator  does  minimal  resource 
acquisition.  All  of  the  MSRR  nodes  have  some  type  of  multi-layer  transaction  based  system  for 
incorporating  resources.  Various  subordinate  organisations  can  play  the  role  of  “resource  co-ordinator,” 
screening  resource  nominations  before  they  receive  final  approval  for  incorporation.  Annual  level  of  effort 
does  not  include  this  role,  as  it  will  vary  significantly. 


URL  stands  for  Uniform  Resource  Locator  (Internet) 
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2.6.7  Weak  Points  Identified 

Development  of  a  sufficiently  robust  administrative  back  end  is  critical  to  maintaining  content.  Originally, 
it  was  assumed  that  many  back  end  functions  would  be  performed  only  occasionally.  As  a  result,  they 
were  not  well  implemented  within  the  administration  back  end.  Some  of  these  functions  are: 

•  Account  administration, 

•  Access  control  by  groups, 

•  Keyword  administration, 

•  System  resets  based  on  external  attacks  or  repeated  entering  of  incorrect  passwords  by  authorized 
users, 

•  Creation  of  new  resource  types,  domains,  and  data  fields. 

2.7  NATO  NC3A  ASSETS 

From  1996  to  1998,  NC3A  was  an  active  participant  of  the  former  Steering  Group  for  Modelling  and 
Simulation  (SGMS,  see  paragraph  1.1).  The  SGMS  organised  a  survey  among  NATO  and  SGMS 
participating  nations  to  know  what  models  and  simulations  were  available  for  application  in  the  NATO 
context.  The  result  of  this  survey  was  made  available  on  the  NC3A  web  site.  It  appears  that  the  database 
has  not  been  maintained  and  is  no  longer  available. 

NC3A  has  developed  a  paper  catalogue  in  1999  describing  tools  developed  or  acquired  by  the  agency. 
This  document  would  be  highly  useful  to  task  group  and  in  the  development  of  a  NATO  SRL,  however, 
the  current  working  status  of  this  document  is  not  known  (unfortunately  no  information  was  available  on 
the  NC3A  website,  (www.nc3a.nato.int ).  It  would  be  useful  if  this  document  could  be  made  available  to 
the  NMSG  in  advance  of  NATO  SRL  implementation. 


2.8  COMMON  POINTS  ON  NATIONAL  PROJECTS  AND  IMPACTS  ON  A 
NATO  SRL 

The  individual  statements  of  participating  nations  positions  in  regard  to  the  development  of  SRLs  show 
that  many  different  approaches  are  planned  and  that  countries  are  at  different  stages  of  implementation. 
The  US  is  the  only  nation  to  have  a  fully  working  SRL.  However,  nations  agree  on  the  pressing 
requirement  for  a  M&S/SE  catalogue,  listing  and  describing  current  assets  owned  or  accessible  to  each 
country,  developer,  user  or  operator  across  all  domains,  (CDE,  MA&S,  Training  or  Mission  Rehearsal 
activities).  In  addition,  participating  countries  are  converging  on  the  common  concept  that  their  catalogues 
must  also  lead  to  a  “common  look  and  feel”.  The  task  group  was  very  interested  to  assess  and  potentially 
exploit  repository  activities  undertaken  by  the  EUCLID  RTP  11.13  programme. 

The  task  group  recognised  that  the  long-term  goal  would  be  a  repository  of  actual  validated  assets,  with 
“one  degree  of  separation”,  i.e.:  a  double  click  of  a  mouse  away  form  the  asset.  However  this  vision  is  not 
feasible  at  this  time. 
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3.1  NEEDS  EXPRESSED  IN  THE  NATO  MSAP  AND  MSMP 

As  mentioned  in  paragraph  1.1.2,  the  NATO  MSAP  objectives  show  clearly  the  need  for  a  NATO  SRL. 
More  specifically,  the  sub-objective  2.3  (see  table  1,  page  3)  is  attached  to  this  activity:  “Establish  a 
Simulation  Resource  Library”.  The  description  of  this  sub-objective  provides  some  details  on  the  contents 
of  the  simulation  library,  but  this  content  list  should  be  considered  as  a  minimum  requirement  for  the  work 
of  this  task  group. 

Sub-objective  1.1  (Adopt  HLA)  mentions  that  no  benefit  could  be  provided  by  a  common  technical 
architecture  without  putting  models  and  simulations  into  a  library  if  they  have  to  be  reused  instead  of 
being  continuously  re-developed. 

Sub-objective  2.1  (Compile  M&S  Information)  is  the  first  sub-objective  explicitly  mentioning  the 
existence  of  a  SRL  as  a  repository  of  information  needed  by  the  NATO  M&S  community  for  its  future 
activity.  It  also  recommends  assessing  what  type  of  information  would  be  suited  to  NATO  and  PfP1 
activity  and  it  is  the  main  topic  treated  in  this  Chapter  3. 

Sub-objective  3.5  (Provide  feedback)  is  the  establishment  of  a  process  to  “provide  information  to 
the  larger  NATO  community  regarding  simulations  and  any  lessons-leamed  during  development”.  This 
sub-objective  suggests  to  record  results  of  the  activity  within  the  SRL  and  the  accomplishment  of  the 
objective  is  clearly  based  on  the  existence  of  such  a  capability. 

Sub-objective  4.5  (Conduct  Impact  Assessment)  is  complementary  to  sub-objective  3.5:  even  if  it  does 
not  explicitly  refer  to  the  SRL,  it  refers  to  the  collection  of  lessons-leamed  and  their  availability  to  future 
developers/users  via  the  MSCO-provided  services. 

Similarly  sub-objective  5.3  (Share  Information)  underlines  the  importance  of  “providing  easy, 
cost-effective  access  to  M&S  related  technology  information”. 


3.2  IDENTIFIED  RESOURCE  LIBRARY  CONTENTS 

The  MSMP  provides  a  very  short  and  not  so  detailed  list  of  products  to  be  included  in  the  NATO  SRL. 
The  sub-objective  2.3  suggests  providing: 

•  End  products:  models  and  simulations, 

•  Raw  materials  (knowledge,  data  and  algorithms  termed  as  “representational  resources”). 

As  recalled  in  the  paragraph  3.1,  some  other  contents  are  suggested  exploring  along  the  MSMP.  This  is  the 
purpose  of  the  next  paragraph  to  be  more  explicit  on  all  possible  contents. 

3.2.1  Contents  Categories 

According  to  experiences  collected  in  different  nations  and  organisations  such  as  the  US  Modelling  and 
Simulation  Resources  Repository  (MSRR),  it  appears  that  contents  of  a  SRL  can  be  very  numerous  and 
diverse.  As  an  illustration,  the  task  group  established  the  following  list.  This  list  should  be  exhaustive  even 


1  PfP  :  Partner  for  Peace 
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if  not  too  detailed.  Pertinent  information  was  classified  in  8  different  categories.  The  accessibility  of 
information  provided  in  each  category  can  be  very  different. 

1.  General  documents:  glossaries,  master/action  plans,  M&S  orientation  courses  and  other  tutorials, 
etc. 

2.  Information  on  M&S  projects:  names,  participating  nation(s),  purpose,  schedule,  point  of 
contact,  etc. 

3.  Links  and  references  to  other  specific  sources  of  information  or  education  materials:  other 
repositories,  related  standard  organisations  (like  IEEE2,  SISO3,  OMG4),  other  communities 
(like  CIS  community). 

4.  NATO  and  national  facilities,  their  capabilities  and  skills:  technical  M&S  centres,  training 
facilities,  battle-labs,  etc. 

5.  Information  about  M&S  end-products: 

•  high-level  description  (M&S  use  domain  e.  g.  training  or  SBA,  level  e.  g.  tactical  or  technical, 
concerned  service  e.g.  Navy  or  Air  Force,  HLA  compliance  status,  etc.), 

•  access  to  detailed  documentation  on  products  or  tools, 

•  assessment  information  (final  reports,  lessons  learned,  reusable  products), 

•  VV&A  status, 

•  access  to  HLA  compliance  certification  documents/reports  and  statistics, 

•  HLA  object  models  (e.  g.  certified  SOMs,  FOMs,  reference  FOMs), 

•  list  of  M&S  supporting  means  (such  as  used  methodology  and  tools)  and  their  high  level 
descriptions, 

•  point  of  contact, 

•  etc. 

6.  Data  sources  (scenarios,  doctrines,  tactics,  performances,  etc.). 

7.  Tools:  help  to  development  and  run-time  tools  (e.g.  FEDEP  tools  database),  specific  APIs5 
(e.g.  SEDRIS). 

8.  M&S  Products  and  raw  materials:  simulations,  models,  technical  documents,  algorithms, 
conceptual  models,  etc. 

3.2.2  Contents  Preferences  among  User  Types 

All  types  of  information  are  not  useful  or  equally  important  for  every  type  of  SRL  user.  The  task  group 
has  identified  5  different  types  of  users: 


2  IEEE  :  Institute  of  Electrical  and  Electronic  Engineers 

SISO  :  Simulation  Interoperability  Standards  Organization 

4  OMG  :  Object  Management  Group 

5  API :  Application  Programming  Interface 
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•  “Beginners”:  this  term  is  related  to  newcomers  to  the  “M&S  activity”  just  discovering  the  M&S 
world  and  the  capabilities  it  offers.  They  can  come  from  any  NATO  nation,  but  they  can  also 
come  from  those  PfP  nations  not  having  already  developed  a  significant  activity  in  M&S. 

•  “Final  users  of  M&S”:  this  generic  term  refers  to  people  who  will  run  or  be  in  direct  contact  with 
simulators,  simulation  applications,  models,  etc.;  they  could  be  students,  analysts,  trainees  or 
trainers;  they  should  have  some  specific  background  about  the  simulation  technology. 

•  “Developers”:  people  in  charge  of  designing,  developing  and  testing  simulations/models;  they  are 
the  real  technical  people  supporting  the  other  categories,  they  should  normally  have  a  good 
general  M&S  culture  and  additionally  some  specific  knowledge  on  one  or  more  speciality  such  as 
software  engineering,  human  behaviour  modelling,  etc. 

•  “M&S  co-ordinators”:  they  can  be  administrative,  political  or  technical  people;  they  should  have 
a  good  background  in  military  affairs.  They  should  have  a  good  understanding  in  M&S;  their  role 
could  be  to  establish  M&S  policy,  to  develop,  co-ordinate  and  run  action  plans,  to  advice  high 
authorities  on  M&S  subjects,  etc. 

•  “Sponsors  /  decisions  makers”:  in  many  cases,  people  from  the  previous  categories  have  no 
power  to  decide  on  their  own  M&S  budget.  Decisions  on  investment  are  made  at  higher  level  and 
requirement  of  “deciders”  are  not  usually  expressed  in  terms  of  M&S.  They  are  rather  expressed 
in  terms  of  functional  capability  such  as  armament  acquisition,  training/exercising  or  decision 
support.  They  should  have  some  technology  basis  to  be  able  to  decide  on  investments. 

For  every  type  of  user  the  importance  of  every  kind  of  information  was  rated  from  “low”  to  “HIGH”  with 
“Medium”  as  an  intermediate  stage. 


Table  2:  Contents  preferences  according  to  user  types 


Beginners 

Final  M&S 

users 

Developers 

M&S 

Co-ordinators 

Sponsors/ 

Decision 

makers 

General 

documents 

HIGH 

Medium 

Medium 

HIGH 

HIGH 

Information  on 
M&S  projects 

Medium 

Medium 

Medium 

HIGH 

HIGH 

Information  on 
M&S  products 

Medium 

HIGH 

HIGH 

HIGH 

HIGH 

Facilities 

Medium 

Medium 

Medium 

HIGH 

HIGH 

Links  & 
References 

HIGH 

Medium 

Medium 

HIGH 

Medium 

Data  sources 

low 

HIGH 

HIGH 

Medium 

Low 

Tools 

low 

HIGH 

HIGH 

Medium 

Low 

M&S  products 
and  raw 
materials 

low 

Medium 

HIGH 

Medium 

Low 
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This  preliminary  assessment  shows  the  different  kinds  of  information  required  by  different  type  of  users  of 
a  simulation  resource  library.  It  shows  that  an  SRL  should  give  access  to  the  first  five  types  of  information 
to  “Beginners”,  M&S  co-ordinators  and  sponsors/decision  makers  within  NATO. 


3.3  CONTENTS  PRIORITISATION 

The  prioritisation  may  directly  be  derived  from  a  thorough  analysis  of  the  boundary  conditions  under 
which  the  TG  was  established: 

•  The  mission  of  NMSG; 

•  National  concern; 

•  The  identified  customers. 

As  the  superior  task  of  NMSG  is  to  promote  and  co-ordinate  the  M&S  activities  within  NATO,  NATO 
members  and  PfP  nations,  the  main  requirement  for  the  NMSG  and  the  M&S  community  is  to  have  access 
to  the  higher  level  of  information.  More  detailed  or  technical  information  should  interest  developers  and 
end  users  that  are  technical  people  of  government  agencies/organisations  and  industry  companies  or 
national  experts. 

Therefore  a  NATO  SRL  should  in  a  first  step  rather  concentrate  on  providing  this  kind  of  information 
rather  than  supporting  detailed  technical  information. 

This  is  in  accordance  with  the  demands  of  the  following  customers: 

•  Beginners, 

•  M&S  co-ordinators, 

•  Sponsors/  Decision  makers, 

who  are  mainly  interested  in  high  level  information  (as  can  be  seen  from  the  previous  table  their  interest  is 
never  low  for  the  five  first  categories  of  information.  Those  categories  are  rated  frequently  “HIGH”  and  in 
some  rare  cases  “Medium”.) 

Consequently,  the  Task  Group  suggests  the  NATO  SRL  to  be  populated  with  information  corresponding 
to  the  first  five  categories  at  highest  priority. 

Furthermore,  technical  and  security  feasibility,  availability  and/or  limitations  in  funding,  required  time 
frames  and  human  resources  issues  also  need  consideration. 

The  development  of  simulation  systems  is  regularly  governed  by  national  responsibility  rather  than  by  the 
Alliance.  This  is  reflected  by  the  current  [technological]  push  for  distributed  simulation  and  the  creation  of 
federations  of  simulations,  such  as  the  NATO  Pathfinder  project. 

Summarising,  the  task  group  recommends  as  a  first  step  to  concentrate  on  building  a  capability  giving 
access  to  a  large  amount  of  information  instead  of  designing  a  repository  providing  M&S  products  and 
software  tools.  These  kinds  of  products  are  recognised  as  keys  for  interoperability  and  reusability,  though 
their  availability  might  raise  some  additional  concerns,  which  should  be  discussed  later  in  some  detail 
(see  Chapter  4). 
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ORGANISATIONAL  SOLUTIONS 

In  this  chapter,  organisational  solutions  are  described  and  compared.  They  form  a  range  from  a  totally 
centralised  approach  to  a  totally  decentralised  solution. 

In  the  centralised  approach,  NATO  or  some  other  authority  maintains  and  owns  the  SRL.  The  entries  in 
the  SRL  do  not  have  to  be  owned  by  the  central  authority,  but  the  ownership  should  be  clear  and  if 
possible  all  contents  should  be  accessible  and  available  to  everyone  within  reasonable  security  and  cost 
limits. 

At  the  other  end  of  the  spectrum  is  a  totally  decentralised  solution  where  the  central  authority  only  owns 
and  maintains  a  “portal”  with  links  to  various  national  and  NATO  resources. 

Between  these  extreme  approaches,  one  finds  various  hybrid  solutions  involving  format  (see  paragraph 
4.1.3)  and  quality  process  controls.  The  format  control  means  how  the  information  regarding  the  resources 
should  be  presented  in  the  SRL.  The  quality  process  is  related  to  frequency  and  procedures  for  supplying 
and  updating  information. 


4.1  SOLUTIONS  DESCRIPTION 

4.1.1  Completely  Centralised 

In  this  section,  the  centralised  approach  corresponds  to  the  completely  centralised  solution.  In  other  words, 
a  single  centralised  server  such  as  that  described  in  the  BDSIM  2000  project  (see  §  2. 2. 2. 2.)  hosts  the  data. 
Hence  the  implemented  solution  will  bring  about  a  centralised  organisation  which  will  require  political, 
organisational  and  financial  issues  as  pointed  out  below. 

NATO  would  need  resources  to  govern  the  capacity  to  manage  such  a  solution.  It  is  clear  that  today  it  does 
not.  It  is  however  less  clear  if  the  Nations  and  their  Industries  have  the  appetite  to  relinquish  sufficient 
local  control  of  their  assets  to  a  central  authority.  Nations  would,  if  such  a  solution  were  to  be  chosen, 
have  to  implement  costly  bandwidth  requirements  to  access  their  own  assets  now  life  cycled  overseas. 

A  centralised  solution  would  also  have  to  comply  with  the  NATO  requirement  of  both  languages  French 
and  English. 

4.1.2  Completely  Distributed 

This  is  the  least  costly  solution.  Basically,  the  Distributed  Libraries  (DL’s)  can  be  accessed  through  a 
“portal”  that  is  a  hub  and  only  keeps  track  of,  and  keeps  updated  links  to,  local  Libraries.  The  “portal” 
would  also  contain  simple  search  algorithms.  The  DL  itself  does  not  govern  in  any  way  the  local  DL.  This 
means  that  these  DL’s  are  likely  to  be  inconsistent  -  and  an  user  would  not  have  any  guarantee  that  the 
library  information  is  valid,  reliable  or  of  high  quality. 

4.1.3  Hybrid  Type  1:  Common  Framework  and  Presentation  Format 

An  user  who  wants  to  access  information  via  the  “portal”  mentioned  above,  would  be  much  helped  if  the 
various  DL’s  are  designed  within  a  common  format  -  and  that  there  is  a  requirement  that  this  format  is 
followed  by  everyone.  The  easiest  way  to  perform  this  is  by  making  benefit  from  the  international  XML1 


1  XML  :  extended  Marked  up  Language 
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standard,  inasmuch  as  an  XML  schema  for  the  SRL  contents  structure  is  offered.  An  example  of  the 
potential  asset  “Simulation  Tool”  is  presented  in  Annex  C. 

The  user  would  then  be  able  to  compare  various  resources  in  order  to  choose  a  resource  that  suits  his/her 
needs.  A  key  issue  of  this  format  would  be  the  list  of  searchable  key  words.  An  example  illustrates  the 
limits  of  having  only  framework  and  format  requirements.  There  can  be  a  format  requirement  that  all 
information  is  dated  -  but  no  requirement  as  to  how  often  information  shall  be  updated.  So  with  this 
approach,  much  information  may  soon  be  out  of  date. 

4.1.4  Hybrid  Type  2:  Common  Quality  Assurance  Procedures 

Here,  all  DL’s  are  accredited.  The  accreditation  requires  that  the  library  follows  a  detailed  sequence  of 
how  the  information  is  updated  and  other  quality  process  issues  are  followed.  In  particular  the  updating 
frequency  requirement  solves  the  problem  of  type  1  -  but  certainly  at  a  significant  cost. 

4.1.5  Hybrid  Type  3:  Common  Framework,  Presentation  Format  and  Quality  Assurance 
Procedures 

This  is  the  solution  that  is  closest  to  a  centralised  solution.  It  differs,  however,  in  that  the  central  authority 
delegates  information  creation  and  information  updating  to  a  localised  authority.  Also,  technically  there  is 
decentralisation;  there  are  local  databases  where  information  resides  with  a  link  to  a  central  “home  page”. 
Other  procedures  are  similar  to  2  above.  But  again,  instead  of  only  requiring  the  DL’s  to  conform  to  a 
quality  process,  now  the  process  itself  is  run  by  a  central  authority.  It  combines  the  requirements  of 
solution  1  and  2  above. 


4.2  COMPARISON  OF  SOLUTIONS 

All  of  the  above  mentioned  solutions  come  along  with  advantages  and  disadvantages,  which  are  discussed 
further  below.  From  experiences  gained  within  the  United  States2,  a  hybrid  solution  seems  favourable. 

Three  main  categories  of  criteria  are  considered: 

a)  Funding  issues: 

•  NATO  costs, 

•  National  costs, 

b)  Labour  issues: 

•  NATO  human  resources, 

•  NATO  training  effort, 

•  National  human  resources, 

•  National  training  effort, 

c)  Practicability  issues: 

•  Initial  Development  effort, 

•  National  requirements, 

•  Consistency  management, 

•  Controllability  by  nations, 


2  For  a  discussion  of  the  US  efforts  on  a  SRL,  see  section  2.6. 
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•  National  security  guarantee, 

•  Intellectual  Property  Rights, 

•  Organisational  effort. 


Table  3:  Solutions  assessment  according  to  the  detailed  criteria. 


Completely 

decentralised 

Hybrid  Type  1 

Common  framework 
&  format 

Hybrid  Type  2 

Quality 

assurance 

Hybrid  Type  3 

(1  plus  2) 

Completely 

centralised 

Funding  issues 

NATO  costs 

++ 

+ 

0 

- 

-- 

National  costs 

-- 

- 

0 

+ 

++ 

Labour  issues 

NATO  human  resources 

+ 

0 

- 

- 

-- 

NATO  training  effort 

++ 

+ 

- 

- 

-- 

National  human  resources 

-- 

-- 

- 

0 

+ 

National  training  effort 

-- 

-- 

-- 

-- 

++ 

Practicability  issues 

NATO  Initial  Development 
effort 

0 

+ 

0 

- 

-- 

Satisfaction  of  national 
requirements 

++ 

+ 

0 

+ 

-- 

Consistency  management  effort 

- 

0 

+ 

++ 

- 

Controllability  by  nations 

++ 

+ 

++ 

++ 

-- 

National  security  guarantee 

++ 

+ 

0 

0 

-- 

Intellectual  Property  Rights 

++ 

+ 

0 

0 

- 

Organisational  effort 

0 

+ 

- 

- 

-- 

This  table  should  be  interpreted  as  an  approximate  assessment.  The  symbol  represents: 

+  /  ++  means  that  this  solution  seems  good/very  good  according  to  this  criterion, 

-  /  -  -  means  that  this  solution  seems  bad/very  bad  according  to  this  criterion, 

0  means  that  this  solution  seems  neutral  according  to  this  criterion. 
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4.3  RECOMMENDED  SOLUTION 

As  discussed  above,  there  are  basically  three  options  to  establish  a  NATO  SRL: 

•  A  fully  centralised  SRL:  all  information  is  owned  and  managed  by  one  central  authority,  and  all 
queries  and  entries  are  to  be  directed  to  this  authority  and  its  database.  Accordingly,  the  required 
staff  to  maintain  the  SRL  is  therefore  significant  at  this  central  authority. 

•  A  fully  decentralised  SRL:  One  central  portal  provides  links  to  a  plethora  (or  not)  of  local 
resources.  Preferably  through  the  Internet,  information  can  be  accessed  and/or  up-  and 
downloaded  from  those  local  databases.  Accordingly,  the  required  staff  is  decentralised. 

•  Hybrid  solutions:  there  is  one  single  server  to  provide  an  access  portal  to  the  SRL;  the  SRL  itself 
comprises  various  decentralised  servers.  In  this  case  the  responsibility  for  maintaining  the  servers 
is  with  the  particular  organisations,  which  run  the  servers  and  only  a  small  staff  is  required  to 
maintain  the  access  portal. 

From  the  NATO  point  of  view,  the  following  table  yields  the  comparison  assessment  of  the  different 
solutions  according  to  the  main  issues: 


Table  4:  Solution  comparison  according  to  the  main  issues 


Completely 

decentralised 

Hybrid  Type  1 

Common  framework 
&  format 

Hybrid  Type  2 

Quality 

assurance 

Hybrid  Type  3 

(1  plus  2) 

Completely 

centralised 

Funding  issues 

+ 

+ 

0 

- 

- 

Labour  issues 

+ 

+ 

+ 

0 

- 

Practicability  issues 

0 

++ 

+ 

0 

-- 

It  appears  reasonable  to  start  with  a  hybrid  approach,  preferably  of  type  1.  The  details  of  what  the 
common  format  control  and  quality  assurance  should  be  will  have  to  be  decided  in  the  SRL  design  and 
implementation  phase.  The  additional  cost  of  that  solution  compared  to  the  cheaper  solutions  seems  to  be 
more  than  overcome  by  its  obvious  higher  quality  and  suitability  to  the  users. 
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OF  A  NATO  SRL 

Starting  from  the  word  “Resource  Library”,  one  would  expect  a  repository,  in  which  resources, 
e.g.  directly  useable  pieces  of  software  or  reference  documents,  are  also  integrated.  From  this  point  of 
view  a  programming  environment,  like  the  J2EE1  may  serve  as  guideline:  J2EE  provides  services  and 
modules,  which  can  be  directly  used  in  a  (distributed)  environment.  The  developer  of  an  application  is 
provided  with  a  brief  description  of  the  capabilities  of  the  service/module  and  its  API2.  The  internal 
structure,  however,  is  hidden  from  the  developer. 

This,  of  course,  is  a  vision  of  a  SRL,  where  the  simulation  systems  are  equipped  with  APIs  expressed  in 
a  standardised  way,  but  one  should  keep  in  mind,  that  a  simulation  system  which  has  been  part  of  an 
HLA-federation  is  already  documented  (at  least  in  terms  of  a  SOM). 

This  chapter  will  develop  the  task  group  proposal  for  the  implementation  of  a  NATO  SRL. 


5.1  VISION  AND  SCOPE 

Presently,  operational  or  projected  implementations  of  simulation  libraries  are  mainly  catalogues  of 
resources.  They  provide  a  very  useful  amount  of  information,  are  often  largely  distributed  and  can 
(or  will)  be  accessed  via  public  or  private  networks.  They  demonstrate  the  availability  of  M&S  resources 
but  they  rarely  provide  a  direct  access  to  the  referenced  resources. 

In  parallel,  a  large  effort  has  been  undertaken  on  interoperability  and  re-use  supported  either  by 
internationally  open  efforts  such  as  the  DIS  and  SISO  communities  or  by  national  government-founded 
initiatives.  All  those  efforts  mainly  started  in  the  90s.  One  of  the  obvious  results  is  the  development  of 
military  interoperability  standards  (such  as  HLA  and  SEDRIS)  and  the  large  adoption  of  industry 
standards  such  as  Java,  XML  UML3,  CORBA4,  etc.  by  the  M&S  community.  At  first  glance,  it  would 
seem  that  a  large  amount  of  technology  is  currently  available  to  interoperate  resources.  Nevertheless,  the 
current  effect  of  this  technology  does  not  seem  to  provide  the  expected  benefit.  Considering  financial  and 
technological  constraints,  the  current  development  of  a  catalogue  is  the  only  possible  and  sensible 
implementation  in  the  short  term. 

In  contrast,  what  is  really  required  by  final  users  is  very  similar  to  what  is  already  operational  within  the 
Advanced  Distributed  Learning  (ADL)  domain:  a  distant,  direct  and  flexible  access  to  simulation 
capabilities  via  a  WAN5  In  the  future,  whatever  the  simulation  purpose  (for  example,  training  or  analysis), 
an  end-user  could  access  and  tailor  an  application  for  it's  own  purpose  on  a  SRL,  run  it  and  obtain  secure 
results  within  a  short  delay.  This  implies  that  models  and  simulations  should  be  made  available  under  a 
dedicated  framework,  that  any  property  or  copyright  issues  be  solved,  that  an  interoperability  level  must 
be  achieved  that  is  beyond  what  is  currently  available.  If  this  vision  could  be  achieved,  users  would  only 
require  to  develop  new  components  that  are  clearly  not  available  to  satisfy  their  full  requirements  and  a 
significant  amount  of  money  would  potentially  be  saved. 


1  J2EE  =  JAVA  2  Enterprise  Edition 

2 

API  =  Application  Programming  Interface 

2 

UML  :  Unified  Modelling  Language 

4  CORBA  :  Common  Object  Request  Broker  Architecture 

5  WAN  :  Wide  Area  Network 
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In  2002  a  follow  on  effort  was  initiated  on  new  interoperability  issues  and  “component  based  simulation” 
willing  to  go  well  far  beyond  what  was  proposed  by  the  HLA  paradigm.  The  idea  is  to  examine  how  the 
current  industry  standards  could  be  used  in  conjunction  with  HLA  and  SCORM  (Shareable  Courseware 
Object  Reference  Model)  ADL  standard  to  establish  distributed  M&S/SE  which  would  be  made  available 
on  WANs  in  a  more  flexible  manner  than  the  current  very  rigid  HLA  federation  concept.  Prototyping 
developments  and  various  studies  are  emerging.  They  should  provide  an  interesting  view  on  what  should 
be  possible  in  the  medium  term  to  provide  this  rapid  and  convenient  resource  use  and  re-use,  which 
constitute  the  future  SRL  vision.  But,  for  the  time  being,  there  is  no  evidence  that  this  vision  is  close  to 
becoming  realistic.  A  lot  of  issues  have  to  be  solved:  they  are  mainly  related  to  security,  database 
availability,  verification  and  validation  issues,  resolution  of  property  and  copyright  issues  in  addition  to 
the  selection  of  the  technical  framework  to  use.  The  continuous  evolution  of  the  technology,  technological 
and  methodological  gaps  to  fill,  constrained  military  budgets  are  not  driving  to  a  close  solution  to  those 
issues.  Nevertheless  the  final  output  of  those  efforts  should  be  kept  in  mind:  ready  availability,  flexible 
access  to  a  distributed  capability  for  the  end-users.  This  vision  shall  lead  the  current  standardisation 
efforts,  the  adoption  of  existing  industry  standards  by  the  M&S  community  and  the  specification  of  future 
SRL  development. 

Further,  it  is  expected  that  a  large  portion  of  this  NATO  SRL  will  be  composed  of  legacy  models  or 
simulations  that  are  stand-alone  tools.  However,  NATO  has  recently  adopted  the  HLA  architecture  and 
individual  nations  have  already  started  to  build  their  own  HLA  -based  architecture,  their  own  synthetic 
environments  and  their  own  applications.  As  a  result,  a  second  key  and  crucial  SRL  task  will  be  for  a 
subsequent  group  to  this  MSG- 12  Task  Group  009  to  outline  a  strategy  that  describes  how  to  enable  not 
just  awareness  but  true  sharing  of  M&S  through  an  “On-Line  NATO  M&S  Portal”  (or  distributed 
controlled-access  servers)  to  some  of  the  HLA-compliant  tools  already  available  in  NATO  nations.  The 
clear  intent  is  to  figure  out  a  strategy  of  facilitating  or  enabling  M&S  use,  re-use  as  well  as  the  user- 
friendly  interoperability  within  the  Alliance. 


5.2  PROPOSAL  FOR  THE  IMPLEMENTATION  OF  THE  SRL 

The  establishment  of  a  distributed  resource  library  has  already  been  tasked  by  several  organisations  and 
programmes.  Hence,  this  task  group  goes  back  to  the  experiences  made  there  to  yield  a  benefit  for  NATO. 

In  particular,  two  European  wide  programmes  were  investigated  for  this  report  in  order  to  benefit  from 
their  lessons  noted:  the  EUCLID  RTP  11.13  (“Realising  the  potential  of  Synthetic  Environments  in 
Europe”)  and  the  ESPRIT6  project  OPERA  (Operators  Training  Distributed  Real-Time  Simulations). 

Both  programmes  have  suggested  the  use  of  architectures  and  technologies  that  rely  on  distributed  object 
technologies  like  CORBA  or  J2EE.  Furthermore,  XML  was  chosen7  as  the  format  for  document8  archiving 
and  exchange. 

5.2.1  Information  Content  of  the  SRL 

Prior  to  drafting  a  possible  architecture  of  the  SRL,  some  light  needs  to  be  shed  on  the  information  that  is 
to  be  stored.  It  is  recommended  that  the  SRL  should  contain  following  information: 

•  Meta-Data:  information  about  an  asset.  In  as  much  as  simulation  systems  are  described  here,  this 
information  is  described  in  section  2.3  plus  indication  of  the  sponsoring  nation  and  references 
about  projects,  where  this  system  has  already  been  used  and  lessons  learned  (if  applicable). 


6  ESPRIT  :  the  EU  information  technology  program 

7  In  RTP  1 1.13  only,  the  ESPRIT  project  was  performed  prior  to  the  acceptance  of  XML  as  a  standard. 

g 

The  term  “document”  is  used  in  a  broader  sense  and  comprises  textual  documents  as  well  as  any  other  piece  of  information. 
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If  reference  material  is  included  in  the  meta  data  an  option  is  required  to  link  the  reference 
document  or  at  least  to  a  point  of  contact. 

•  Model  Data:  information  about  the  data  structure  as  far  as  relevant  for  communication,  expressed 
in  an  agreed  standard  format,  e.g.  XML  (with  a  specified  scheme/DTD9)  or  HLA  OMT10. 

•  Supporting  Tools:  it  is  recommended  to  include  the  FEDEP  Tools  list,  as  prepared  by  MSG-005 
into  the  SRL. 

•  Linkage  either  to  the  simulation  system  itself  (ideal  case)  or  at  least  to  a  point  of  contact.  In  the 
first  case  the  link  should  provide  the  signature  of  the  simulation  system* 11  and  the  API. 

A  suggestion  of  the  information  content  is  given  in  the  Annex  C  as  an  example  of  an  XML  Schema.  This 
schema  corresponds  to  the  format  as  mentioned  in  section  4.1.3. 


5.2.2  Architecture  of  the  SRL 

Following  the  references  given  further  above,  the  task  group  proposes  a  3-tier  architecture  for  the  SRL. 
Although,  more  recent  developments  on  distributed  databases  allow  even  for  more  tiers,  it  is  recommend 
to  exploit  a  regular  3 -tier  architecture  following  experiences  from  the  RTP  11.13  project. 


In  the  presentation  tier  the  client  gets  access  to  the  repository  services  by  using  SOAP  (Simple  Object 
Access  Protocol)  messages  over  HTTPS  (Secure  HTTP12).  The  use  of  these  technologies  enables  access 
over  the  Internet  as  well  as  via  a  local  web  server.  The  Web-Server  and/or  SOAP  Handler  need  to  be 
embedded  into  a  transaction  administration  layer:  it  is  responsible  for  granting  the  parallel  access  of 
various  users.  More  importantly,  it  has  to  take  care  that  changes  in  the  database  are  either  performed 
completely,  or  are  totally  neglected  (an  all-or-nothing  principle).  This  is  to  guarantee  consistency  of 
objects. 


1 

/  Local  / 

/  Local  / 

/  Local  / 

/  Entry  / 

/  Entry 

/Entry 

/  Manager 

/  Manager 

/  Manager 

Internal  Store  s 

Internal  Store  s 

1  Internal  Store  j 

External  Store 


External  Store 


External  Store 


Data  Tier 


Figure  3:  Proposal  of  a  3-tier  architecture  for  the  SRL 


DTD  :  Document  Type  Definition 

10  HLA  OMT  :  HLA  Object  Model  Template 

1 1  Signature  =  required/accepted  input  and  output  data 

12  HTTP  :  Hyper  Text  Transfer  Protocol 
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The  middle  tier  comprises  an  Object  Manager  or  Access  Control  and  a  Local  Entry  Manager.  The  first 
should  enable  a  consistent  object- view  upon  the  data.  It  is  responsible  for  the  object  and  class  structure 
administration.  Finally,  an  Entry  Manager  is  responsible  for  accessing  the  data  storage;  it  exposes  an  API 
to  the  clients  to  provide  functions  to  them  like  storing,  deleting,  retrieving,  etc.  It  has  the  ability  to  create 
inputs  on  behalf  of  the  client  most  preferably  as  updateable  XML  DOM13  objects. 

The  data  tier  finally,  comprises  a  Data  Store  Manager  responsible  for  converting  the  objects  resident  in  the 
local  store  (connected  through  pointers)  into  persistent  data  structures. 

Summarising: 

The  presentation  tier  allows  the  user  to  access  the  SRL  e.g.  via  a  Web  server;  the  middle  tier  is  responsible 
for  decoding  the  incoming  messages  and  routing.  Additionally,  the  middle  tier  could  also  comprise  further 
service  units,  e.g.  security  devices,  query  managers  etc..  The  implementation  of  deeper  layers  in  the 
middle  tier  (everything  after  the  Object  Manager)  is  left  to  the  national  responsibility  and  authority. 

5.2.3  Recommended  Technologies 

In  order  to  guarantee  platform-  and  language  independence,  the  use  of  products  complying  to  OMG 
standards  is  recommended. 

In  particular: 

•  SOAP/HTTPS  as  the  interaction  and  transmission  protocol  between  Client  and  Server  modules; 

•  XML  as  the  document  archiving  and  exchange  format  with  e.g.  using  the  SAX14  API  parser  for 
searching  XML  documents; 

•  Java  Integrated  Development  Environment  (IDE)  for  developing  the  client/server  architecture. 

5.2.4  Conclusions  and  Recommendations 

The  focus  of  the  architectural  description  of  the  SRL  is  to  enable  a  generic,  distributed,  multi-user 
application  which  allows  for  searching,  retrieving  and  uploading  of  information  from  different  locations 
spread  over  interested  NATO/PfP  nations. 

From  a  technical  point-of-view,  a  3 -tier  architecture  is  proposed;  after  thorough  discussion,  the  group’s 
view  of  the  repository  is  mostly  that  of  an  information  and  storage  service. 

As  opposed  to  true  object  servers  such  as  COM15  and  CORBA,  this  repository  will  not  have  the  ability  to 
install  a  user  (i.e.  tool)  specific  function  on  the  server.  However,  the  repository  should  provide  a  generic 
XML  DOM-like  API  for  server-side  entry  manipulation. 

In  future  extensions  of  the  SRL,  one  might  think  of  implementing/accessing  tool’s  functionality  directly 
through  the  server. 


5.3  SECURITY  ASPECTS 

It  is  commonly  agreed  that  the  complexity  of  providing  an  adequate  level  of  security  increases  with  the 
number  of  users  and  the  wider  information  is  shared.  From  the  original  idea  to  share  information  as  wide 

13  XML  DOM  :  XML  Document  Object  Model 

14  SAX  :  Simple  API  for  XML 

15  COM  :  Component  Object  Model 
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as  possible  among  NATO/PfP  Nations  it  is  apparent  that  the  initial  version  of  the  SRL  will  not  contain  any 
protectively  marked  information  as  it  is  designed  to  be  accessible  from  the  Internet. 

There  are  various  protective  measures  commercially  available.  Since  the  SRL  in  its  first  demonstration 
should  not  contain  classified  information,  the  use  of  such  measures  seems  adequate  and  sufficient.  If,  in 
future  extensions,  more  sophisticated  measures  become  necessary  the  architecture  proposed  here  is  simple 
enough  to  allow  for  adjustments.  Technologies  readily  available  for  protecting  data  over  the  public 
telecommunication  network  include  secure  Internet  Protocol  (IPSec),  Virtual  Private  Networks  (VPN), 
encryption  devices  and  Public  Key  Infrastructure  (PKI),  among  others. 

The  task  group  —  following  recommendation  given  within  the  RTP  11.13  programme  —  refers  to  an  UK 
initiative16.  There,  the  concept  of  “Common  Criteria”  is  defined.  This  is  a  standard  that  can  be  used  as  a 
basis  for  evaluating  security  products  (called  as  Target  of  Evaluation,  ToE)  by  permitting  comparability 
between  the  results  of  independent  security  evaluations. 

The  Common  Criteria  defines  the  following  framework: 

•  Security  environment:  Laws,  regulations,  organisational  security  policies  etc.  which  define  the 
context  in  which  the  ToE  is  to  be  used.  Threats  present  in  the  environment  are  also  included. 

•  Security  objectives:  This  is  simply  a  statement  of  intent  to  counter  the  identified  threats  by  IT17 
measures. 

•  Security  requirements  for  the  ToE:  The  refinement  of  the  IT  security  objectives  into  a  set  of 
technical  requirements  for  security  functions  and  assurance. 

•  Security  Specifications  for  the  ToE:  Define  an  actual  or  proposed  implementation  for  the  ToE. 

•  Implementation  of  the  ToE:  The  realisation  of  a  ToE  in  accordance  with  its  specification. 

The  Common  Criteria  are  currently  recognised  by  Canada,  France,  Germany,  the  Netherlands,  Norway 
UK  and  US.  They  are  being  considered  for  use  by  the  EUCLID  RTP  11.13  consortium. 


5.4  POPULATION  AND  MAINTENANCE  OF  THE  SRL 

Although  technically  feasible,  for  the  sake  of  consistency  as  well  as  security,  it  is  recommended  to  follow 
a  population  process  as  outlined  further  below  rather  than  a  decentralised  population. 

5.4.1  Population  Process 

As  well  as  the  initial  or  future  population  of  the  NATO  SRL,  the  list  of  imperative  tasks  is: 

•  creation, 

•  modification, 

•  destruction, 

•  verification, 

•  validation. 

The  terms  “verification”  and  “validation”  refer  to  the  SRL  information  and  not  to  the  VV&A  of  models 
and  simulations  referenced  in  the  database.  The  task  “verification”  has  the  purpose  to  verify  that  the 


10  1 
www.cesg.gov.uk. 

17  IT  :  Information  Technology 
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information  is  produced  in  the  adequate  format  and  is  complete.  The  validation  is  supposed  to  check  that 
the  information  is  semantically  correct. 

Each  agent  in  charge  of  the  SRL  population  process  must  be  able  to  carry  out  these  actions  through  an 
appropriate  network.  A  Web-based  end-user  interface  appears  as  a  good  candidate  for  processing  these 
actions. 

Before  describing  an  SRL  population  process  including  the  verification  and  the  validation  processes,  let  us 
define  the  minimum  stakeholders  involved  in  the  population  process: 

•  Authorised  National  Organisations  (ANO):  National  organisations,  which  are  authorised  to 
have  an  access  to  the  SRL.  Because  of  the  peculiarity  of  the  national  M&S  organisations,  each 
nation  has  to  manage  directly  the  access  rights  of  their  ANO. 

•  NATO  SRL  Verification  Agent  (NSVeA):  National  -  or  MSCO  staff  if  the  verification  is 
centralised  at  the  NATO  level  -  whose  task  is  to  check  the  format  and  the  completeness  of  the 
information  according  to  the  defined  population  interface. 

•  NATO  SRL  Validation  Agent  (NSVaA):  National  -  or  MSCO  staff  if  the  validation  is 
centralised  at  the  NATO  level  -  whose  task  is  to  validate  the  verified  information,  insert  them  into 
the  NATO  SRL  and  send  a  notification  to  the  ANOs. 

The  above  stakeholders  can  be  a  unique  person  or  different  agents,  depending  on  the  final  decision  made 
by  NATO  authorities. 

Let  us  now  give  a  description  to  the  population  process.  When  an  ANO  fills  out  the  population  form,  he  or 
she  should  send  a  request  to  the  NSVeA  for  creation,  modification  or  destruction.  It  is  considered  that  the 
information  given  by  the  ANO  have  been  verified  and  validated  at  the  national  level  according  to  an 
appropriate  organisation. 

The  NSVeA  verifies  the  completeness  of  the  information  according  to  the  data  specifications.  If  this  step 
fails,  the  NSVeA  sends  back  the  request  to  the  ANO  for  revision,  otherwise  the  NSVaA  validates  the 
information  and  sends  a  notification  to  the  ANO.  Then  related  data  are  allowed  to  be  published. 

In  case  of  a  modification  or  a  destruction  request,  the  previous  versions  should  be  stored  into  an  archive 
for  the  configuration  management. 

The  following  figure  4  shows  the  population  mechanism  described  above. 

In  the  case  of  a  product  developed  in  co-operation  or  shared  by  nations  the  item  should  be  referenced  in 
only  one  SRL  for  configuration  control.  In  that  case  a  nation  should  be  designated  as  the  custodian  of  the 
related  information.  For  example,  in  a  typical  EUCLID  project,  the  lead  nation  should  be  in  charge  of  this 
task. 

Some  products  are  developed  by  NATO  agencies  and  are  not  typically  used  by  nations.  This  justifies  the 
requirement  of  a  specific  NATO  node.  This  node  could  be  set  up  in  the  RTA  or  the  NC3A.  This  second 
possibility  has  not  been  considered  due  to  the  absence  of  a  NC3A  representative  in  the  task  group. 
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Ask  for  revision 


Notify  the 
publication 


Figure  4:  Population  mechanism 


5.4.2  Maintenance  Process 

The  maintenance  of  the  information  is  under  the  responsibility  of  the  national  M&S  organisations. 
As  expressed  in  the  previous  paragraph,  a  national  verification  and  validation  process  should  achieve  it. 
Whatever  the  final  solution  selected,  it  has  should  be  emphasised  that  backup  hardware  systems  are 
required  for  the  storage,  the  configuration  management  and  the  safety  of  the  NATO  SRL. 

Besides  this  aspect,  it  is  also  important  to  pay  attention  to  the  NATO  SRL  access  availability,  the  software 
and  the  hardware  maintenance.  Then  a  central  administrator  is  necessary.  It  should  be  the  responsibility  of 
the  RTA/MSCO  or  the  NC3  A. 
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5.4.3  Authority  for  Asset  Population 

The  population  and  maintenance  process  will  require  significant  human  and  funding  resource.  The  likely 
level  of  human  resources  to  manage  the  SRL  are  set  out  in  paragraphs  5.4.1  and  2.  There  will  be  additional 
resource  requirements  for  the  initial  population  stages.  Development  of  a  process  is  required  to  capture  the 
assets;  in  the  past  this  has  often  been  achieved  by  the  form  of  questionnaire,  however  more  benefit  would 
be  obtained  by  use  of  personal  communication  between  the  stakeholder  and  the  persons  populating  the 
SRL.  Senior  levels  of  NATO  need  to  agree  and  authorise  the  asset  capture  process  and  subsequent 
accessibility  to  assets  that  are  contained  within  the  SRL.  It  is  unlikely  that  the  NMSG  is  the  responsible 
body  to  issue  this  authorisation;  NMSG  do  not  own  or  manage  the  data  or  assets.  The  NMSG  should 
approach  the  RTB  to  determine  who  can  authorise  the  asset  capture  process.  Co-operative  working  with 
NC3  A  should  be  encouraged. 

In  addition,  Terms  of  Reference  for  National  or  NATO  individuals  who  partake  in  asset  capture  should  be 
drafted,  reflecting  their  given  authority.  A  senior  NATO  body  should  endorse  the  TORs. 

To  be  effective  the  SRL  would  require  access  to  assets  from  existing  projects  and  to  new  assets  as  they 
become  available.  A  senior  NATO  body  should  mandate  that  information  on  all  assets  that  are  developed 
in  support  of  new  programmes  should  be  delivered  to  the  SRL. 

NATO  needs  to  identify  the  key  assets  it  would  like  to  store  in  the  SRL.  There  are  reference  papers  on 
asset  characterisations  available  from  the  EUCLID  11.13  work  package  3  deliverables18.  As  a  follow  on 
activity  NATO  should  work  with  the  EUCLID  11.13  consortia  on  the  creation  of  NATO  specific  DTDs  or 
schema  for  population  of  the  SRL. 


5.5  HUMAN  AND  FUNDING  RESOURCES 

Collecting  statements  from  various  places  within  this  report,  this  paragraph  summarises  the 
recommendations.  As  mentioned  earlier  in  this  report,  the  establishments  of  a  SRL  needs  1-2  persons 
and  a  budget  of  approximately  500  k€  for  acquisition  of  hard-  and  software  and  logistic  support19.  After 
the  SRL  is  established,  only  a  minor  budget  is  necessary.  It  is  assumed  that  one  full-time  position  and  an 
annual  budget  of  50  k€  is  sufficient  within  the  centralised  part.  As  far  as  the  decentralised  parts  is 
concerned,  an  exact  cost  estimation  depends  upon  national  regulations.  As  a  rough  number,  one  can 
estimate  a  quarter-time  position  with  an  annual  budget  of  10  k€  for  each  participating  nation. 


5.6  PROPOSAL  FOR  A  SRL  DEVELOPMENT  PLAN 

The  key  milestones  to  develop  a  NATO  SRL  are  set  out  below. 

The  milestone  dates  are  based  on  the  assumption  that  this  report  (NMSG  012  -  TG  009)  is  finished  by 
February  2003.  (This  recognises  that  the  document  may  not  be  in  print  at  that  time.) 

In  addition  the  NMSG  needs  to  consider  and  decide  whether  there  is  a  requirement  to  link  to  other 
repositories,  for  example,  the  US  MSRR  and  EUCLID  11.13  repositories. 


1 8 

See  references  to  EUCLID  documents  in  Annex  D. 

19 

Logistic  support  comprises  collecting  assets  to  populate  the  SRL;  it  is  assumed  that  this  requires  having  bespoke  meetings 
with  the  potential  stakeholders;  thus  logistic  budget  means  travelling  and  communication  cost  (e.g.  video-conferencing, 
etc.). 
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Approval  of  report  and  development  plan  by  NMSG 

April  2003 

Approval  of  report  and  development  plan  by  the  RTB 

Sept  2003 

Draft  of  budget  levels  and  requirements  documents  distributed  to  nations 

Sept  2003 

Funding  secured  by  MSCO 

Oct  2003 

Development  plan  agreed  and  funding  secured  by  NMSG 

May  2003 

Secure  involvement  of  NATO  and  4  nations 

Oct  2003 

Endorsement  of  policies  by  NATO  senior  level  committee(s) 

Nov  2003 

Agreement  on  detailed  technical  implementation  architecture 

Dec  2003 

Identification  of  suitable  project  staff 

Dec  2003 

Start  of  SRL  project  work 

Jan  2004 

Prototype  implementation  presented  at  the  NMSG  meeting 

May  2004 

Requirements  reviewed  by  NATO  and  Nations 

June  2004 

First  “official”  implementation 

Sep  2004 

Stamp  of  approval  by  NMSG 

Oct  2004 

Official  launch 

Jan  2005 

SRL  implemented 

Jan  2005 
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ORGANIZATION 
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Chapter  6  -  CONCLUSIONS  AND  RECOMMENDATIONS 

6.1  PROPOSAL  FOR  A  NATO  SRL 

The  task  group  recommends  the  development  of  a  NATO  SRL.  The  proposed  architecture  for  the  SRL  is  a 
distributed  library  with  a  common  framework  and  presentation  format.  The  SRL  should  be  composed  of 
national  nodes  and  at  least  one  NATO  node.  The  NATO  node(s)  could  be  managed  either  by  RTA/MSCO 
or  NC3A.  It  is  however  the  task  group’s  suggestion  that  the  central  node  is  managed  by  the  MSCO  in 
accordance  with  the  NATO  MSAP.  Consequently  a  sufficient  level  of  annual  funding  and  human 
resources  must  be  established  to  set  up  and  maintain  a  quality  service. 

The  group  noted  that  the  longer-term  vision  is  to  have  a  repository  with  a  common  framework, 
presentation  format  and  quality  assurance  process.  However  from  the  practical  point  of  view  it  is  advisable 
to  start  to  develop  an  SRL  with  only  the  common  framework  and  presentation  format.  The  degree  of 
centralisation  of  the  above  options  is  solely  through  the  use  of  a  central  web  portal.  The  distinction 
between  a  library  and  repository  in  this  context  is  that  a  repository  could  contain  downloadable  assets, 
which  is  a  part  of  the  task  group’s  long-term  vision. 

Chapter  3  discusses  the  potential  assets  that  can  be  stored  in  an  SRL.  These  include  general  documents, 
information  on  M&S  projects  and  products,  facilities,  links  and  references.  The  minimum  inputs  to  the 
SRL  should  include  a  description  of  the  assets,  that  is  “meta-data”,  and  include  a  point  of  contact. 

The  key  criteria  used  in  choosing  the  suggested  technical  solution  were  the  need  to  minimise  costs  and 
human  resources  and  to  capitalise  on  existing  architectures  and/or  achievements.  The  group  recognised 
however  that  under-funding  of  the  SRL,  especially  in  the  development  phase,  will  severely  hinder  the 
implementation  of  an  essential  requirement  for  the  nations  and  NATO. 

The  suggested  technical  solution  is  closely  related  to  the  achievements  of  EUCLID  RTP  11.13, 
(“Realising  the  potential  of  networked  simulation  in  Europe”)  and  is  based  on  the  use  of  current  Internet 
technologies.  The  proposed  solution  is  the  establishment  of  a  distributed  network  of  nodes,  each  of  which 
is  under  the  authority  of  Nations  or  NATO  organisations.  The  group  developed  an  XML  schema  as  a 
starting  point  for  the  recommended  solution  with  a  common  framework  and  presentation  format 
(see  Annex  C).  The  task  group  recommends  that  strong  links  are  maintained  with  the  EUCLID  11.13 
consortium  in  the  establishment  of  the  SRL  and  that  possible  sharing  and  exploitation  of  existing 
achievements  are  considered. 

The  recommendations  for  security  are  in  line  with  work  on  “Common  criteria”  developed  by  the 
Communications-Electronics  Security  Group  (CESG). 

It  is  estimated  that  the  cost  to  NATO  for  the  development  phase  for  the  establishment  of  the  SRL  will  be 
1-2  persons  and  a  budget  of  approximately  500  k€.  This  includes  acquisition  of  hardware  and  software 
and  logistic  support.  Nations  will  have  similar  overall  costs  depending  upon  their  current  status  of  SRL 
activities.  After  the  SRL  is  established,  a  lesser  budget  should  be  required.  It  is  proposed  that  one  full-time 
position  and  an  annual  budget  of  50  k€  will  be  sufficient  to  manage  and  maintain  the  centralised  part.  As 
far  as  the  decentralised  parts  (National  nodes)  are  concerned,  an  exact  cost  estimation  depends  upon 
national  regulations.  As  a  rough  number,  one  can  estimate  a  quarter-time  position  with  an  annual  budget 
of  10  k€  for  each  participating  nation. 

The  task  group  recommends  that  the  SRL  should  be  implemented  by  January  2005.  The  schedule  will  of 
course  be  dependent  upon  securing  approval,  authority  and  finance  from  the  NMSG  and  the  RTB. 
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6.2  RECOMMENDATIONS  TO  THE  NMSG  AND  THE  RTO 

The  task  group  recommends  that  the  NMSG  approves  this  report  and  reports  the  main  conclusions  and 
recommendations  to  the  RTB.  Through  the  RTO  the  necessary  funding  and  human  resources  should  be 
secured  to  implement  the  SRL  in  line  with  the  proposed  development  plan  (Section  5.6);  this  proposes  a 
launch  date  of  January  2005  for  the  NATO  distributed  SRL.  The  financial  requirements  and  human 
resource  requirements  are  set  out  above.  The  RTA  has  already  requested  the  creation  of  two  new  positions 
for  implementing  and  managing  the  MSCO  help-desk  and  the  SRL.  Population  and  maintenance  of  the 
SRL  will  require  the  agreement  and  authority  of  the  NMSG  (see  Section  5.4.3). 

The  main  NATO  M&S  assets  are  developed  or  acquired  by  NC3A,  therefore  strong  involvement  of  NC3A 
is  required  for  the  establishment,  population  and  maintenance  of  the  NATO  node(s).  It  is  recommended 
that  the  NMSG  and  above  authorities  request  the  support  of  NC3A. 
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Name: 

Acronym: 

Type: 

Description: 

Purpose  or  Domain 

Analysis: 

Acquisition  &  Support: 

Training  Operations: 

Other: 

Details 

Model  Type: 

Simulation  Type: 

Network: 

Supported  Capability  Components:  xxxx 

Other  User: 

Ease  of  Use: 

Release  Date: 

Lifespan: 
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ORGANIZATION 


Organization: 

Mailing  Address: 

Phone: 

Fax: 

Email: 

URL: 

Additional  Information 

Other  Info: 

Keywords: 

Projects 


Case  Studies 

•  Make  Comments 

•  Add  Project 

•  Add  Case  Study 

•  Add  New  Resource 
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ORGANIZATION 


USER  PROFILES 

The  different  user  profiles  identified  in  the  database  are  described  in  the  following  table: 


User 

Profile 

Rights 

How  they  are 
identified? 

UT 

Utilisateur  final  (End  user) 

Read 

Subscription 

CE 

Correspondant  d’Entite 
(Organisational  point  of  contact) 

Creation,  modification, 
suggestion  to  delete  data 

Designated  by  the 
competent  authority 

AE 

Administrates  Etatique 
(Government  Administrator) 

Validation  and  deletion  of  data 
Creation  of  user  accounts 

Designated  by  the 
competent  authority 

AT 

Administrates  Technique 
(Technical  administrator) 

Data  base  administration 
Creation  of  user  accounts 

Designated  by  the 
competent  authority 

ORGANISATION 

The  figure  below  is  a  diagram  of  a  high  level  user.  It  shows  BDSIM  and  its  environment  and  shows  how  it 
works. 

Please  notice  that: 

•  The  participants  (User  groups)  with  whom  the  system  interacts  (UT),  (CE),  (AE)  and  (AT), 

•  When  in  use,  as  shown  by  the  oval,  one  may  translate  here  as  a  subset  of  the  functionality  of  the 
system, 

•  Participants’  use  (solid  arrow). 
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ARCHITECTURE  OF  BDSIM  2000 


Hebergeur 


Architecture 


HARDWARE  AND  SOFTWARE  CONFIGURATIONS 


Hardware  Configuration 

Software  Configuration 

HTTP 

Server 

•  Dell  Power  Edge  2500 

•  Pentium  III  lGhz 

•  256  Ko  de  cache 

•  1  Go  RAM 

•  18  Go 

•  Operating  system:  Windows  2000  Server  (5  access) 

•  Server  HTTP  IIS  5.0  (MS),  environment  ASP  et  COM  (MS) 

•  COTS  software  MASC  &  SIM  (company  ARCHIMED  SA): 
one  licence  server  and  one  hundred  licences  for  the  access 

•  Module  server  for  PDF  conversion 

•  Backup  software  :  ArcServe  2000 

Data 

server 

•  Dell  Power  Edge  4400 

•  Pentium  III  lGhz 

•  256  Ko  Full  Speed 

•  512  Mo  RAM 

•  RAID  5  *  18  Go 

•  Operating  system:  Windows  2000  Server  (five  access) 

•  SQL  Server  2000  (Microsoft,  licence  Web) 

•  Backup  software:  ArcServe  2000. 
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SECURITY 

Making  the  Hardware  Secure 

Hardware  security  is  founded  upon  the  following  points: 

The  technical  architecture  provided  by  the  host  ensures  security  through  various  means  (DMZ,  protected 
area,  firewall);  in  particular,  only  the  DMZ  Web  server  may  access  the  protected  area,  which  is  not 
accessible  from  the  Internet. 

Site  access  is  controlled  by  a  login/password  mechanism  (according  to  the  standard  SSL  V2)  and  from  the 
management  of  the  user  profiles  (UT;  CE;  AE  and  AT). 

In  addition  a  filtering  of  the  IP  address  is  put  in  place  and  controlled  by  the  AE  and  the  AT  users. 
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PUBLICATION  PROCESS 


* 


* 


X  % 


Process  of  Populated  Form  Creation 
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£ 


CE 


£ 


:BDSIM2000  system 


Step  Ik  Requestfor  deleting 

rJ~1  1:  Request  for  deleting  a  populated  form 


3:  Fill  up  reason  of  deleting 

=1 


Step  2 


2:  Display  the  request  deleting  form 


4:  Confirm  deleting  request 


:  Treatment  of  deleting  request 


11:  Send  one  e-mail  to  AE 


16:  Send  one  e-mail  to  AE 


tt 


5:  Register  the  request  in  BDD 

6:  Send  one  e-mail  to  AE 


□ 


7:  Find  the  deleting  request 


8:  Display  the  deleting  request 


9:  Accept  the  deleting  request 


10:  Update  BD 

^=3 


I 


12:  Refuse  the  deleting  request 


13:  Display  the  reason  of  refuseform 


15:  Confirm  refuse 


£ 


AE 


n 


Accept 


Refuse 


5 


3 


14:  Fill  up  reason  of  refuse 

L-r  I 


Process  of  populated  form  deleting 
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Annex  C  -  EXAMPLE  OF  AN  INFORMATION 
DESCRIPTION  USING  XML  SCHEMA 

The  following  figures  depict  the  content  structure  of  the  SRL  asset  “Simulation  Tool”.  The  figures  are 
generated  by  use  of  an  XML  tool  and  represent  excerpts  from  a  XML  schema.  This  is  a  hierarchical 
structure  of  categories  used  to  classify  an  arbitrary  simulation  tool. 

The  top-level  information  categories  are  depicted  below. 


SimTool 


^ 


Any  software  related  to 
M&S; 


Generallnrformation 


i 


Name,  Sponsor,  POCs,  etc. 


MilitaryUse  [+] 


List  areas  of  application, 
where  the  product  is  used. 
Plain  text  as  description 
allowed. 


Features 


List  of  features  that  describe 
the  model  behind  the  product 


Software 


5 


List  technical  information 
about  SW 


HardwareRequirements  [+] 

List  Requirements  on  I-IIA1 


VV 


Validation  a.  Verification: 
State,  whether  there  is  a 
Testbed  and  if,  which  testing 
processes  have  been  applied 


EKistingLinks 


Specify  URL  to 
download/acces  asset  (if 
applicable) 


Top  level  information  of  SimTool 


If  a  connection  to  existing  nodes  is  required  (for  example  a  link  to  the  U.S.  MS  SR,  the  link  can  be  easily 
added  within  the  XML  file  as  indicated  by  the  entry  filed  “ExistingLinks”. 

For  practical  reasons  it  is  desirable  to  have  general  information,  to  enable  contacting  the  developer  and/or 
user  to  get  some  practical  advice. 
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Is  the  Sw  maintained?  IF 
yes,  give  details  (GE: 
SWPA) 


Second  level  information  SimTool/General  Information 


For  the  use  within  a  particular  project,  information  of  the  military  domain  in  which  the  tool  could  be  used 
is  relevant. 


Is  the  product  a  database?  IF 
Yes,  specify  Format, 

Features,  etc, 


Second  level  information  SimTool/  Military  Use 
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Especially,  for  issues  concerned  with  validation  and  verification,  knowledge  of  certain  “features”  is 
required. 


Features 


List  of  features  that  describe 
the  model  behind  the  product 


Representation 

What  does  the  product 
represent?  Tick  from  the  list. 

Resolution 

Specify  echelon  and/or 
details 

= DescriptionOfModel 

Specify  algorithms,  thoretical 
models  and  whether  there  is 
documentation  available. 

=AppliedProcessModel 

Specify,  how  the  product  was 
created:  e.g.  Process  Model; 

Used  Tools;  Methodology 

'LimitationsOfModel  | 

Specify  the  limits  of  the 
model;  what  details  of  the 
real  world  are  neglected? 

= PrecisenessOfModel 

Specify,  how  precise  the 
model  is 

=Parametrics  | 

Specify,  if  model  is  driven 
by  parameters;  or  if 
parameters  can  be  modified 

=ClassificationOfModel  | 

Specify:  Modul,  Legacy,  closed, 
etc. 

~TimeManagement  | 

Specify  Time  Mgt :  Realtime, 
Walldock,  etc. 


Second  level  information  SimTool/Features 


When  entering  a  stage  on  a  more  technical  level,  finally,  information  related  to  soft-  and  hardware 
requirements  becomes  valuable. 
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Specify  required  libs 


Second  level  information  SimTool/Software 


"OS 

Specify  Operating  System 


HardwareRequirements 


\ 

s 


List  Requirements  on  HW 


Memory 


SpeciFy  Memory  (RAM, 
SharedMemoiy,  ScramNet, 
etc,) 


Dependencies  ffl 


Specify  the  following: 
databases.  Interfaces, 
COTS,  Commlnfrastructure, 
Licenses 


HetworkConnection 

Connection  to  a  network 
possible?  Specify 


Second  level  information  SimTool/Hardware  Requirements 
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n  J-L  *-L  J-t  *-L  J-J  J-L I-L  J1.  I J-L  J-L  1 

/ 

UcpcIlUcllUcS  [”] 

Specify  the  following: 
databases,  Interfaces, 
COTS,  Commlnfrastructure, 
Licenses 


Database 


Specify  details  about 
envimmental  database  (if 
applicable) 


Interfaces 


Specify  details  about 
interfaces  (internal, I'extemaD, 
standard? 


COTS 


*7- 

1  ..oo 

Are  COTS  products 
necessary  to  run  the  tool.  If 
yes,  specify 


Commlnf rastructure 


1  ..oo 

Does  the  depend  on  a  special 
communicationinfrastructue 
eg.  RTI).  If  yes,  specify. 


Licenses 


1 


.00 


Specify  dtails  about  licensing 
procedure,  if  possible. 


Third  level  information  SimTool/HardwareRequirements/Dependencies 
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(Many  relevant  references  can  be  found  on  some  key  web-site) 

CESG  (Communications-Electronics  Security  Group)  http://www.cesg.gov.uk 

OMG  (Object  Management  Group)  http://www.omg.org 

US  DoD  Defense  M&S  Office  (DMSO)  http://www.dmso.mil/public 

EUCLID  RTP  11.13  Web  site  http://www.euclidl  1 13.com 

EUCLID  RTP  11.13  Ref  #1: 

“Method  for  Characterising  Repository  Assets”, 

(Technical  Note  3.1.c), 
dated  2  May  2002 

EUCLID  RTP  11.13  Ref  #2: 

“Repository  Architecture” 

(Technical  Report  8.1) 
dated  13  December  2001. 

ESPRIT  :  “European  Strategic  Programme  for  Research 
and  Development  in  Information  Technology” 

NATO  M&S  Action  Plan 

NC3A  Operations  Research  Division 
“Models  and  Planning  Tools  Descriptions” 


http  ://www.  cordis .  lu/  esprit/home  .html/ 

http://www.rta.nato.int/msg.htm 

Compilation  document  by  R.  J.  Goad, 
NC3A  ORD  in  July  1998 
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ADL 

Advanced  Distributed  Learning 

AMS 

Alenia  Marconi  Systems 

ANO 

Authorised  National  Organisations 

ANPROS 

ANtenne  Plan,  Recherche  Operationnelle  et  Simulation  (operational  research  and 
simulation  center  of  the  Navy,  France) 

API 

Application  Programming  Interface 

ARCOSIM 

ARchitecture  COMmune  de  SIMulation  (France) 

ASCII 

American  Standard  Code  for  Information  Interchange 

BDSIM 

Base  de  Donnees  de  SIMulation  du  ministere  de  la  defense  frangaise  (simulation 
database) 

CA 

Canada 

CAD 

Centre  d’ Analyse  de  Defense  (Center  of  Defense  Analysis) 

CASE 

Canadian  Aerospace  SE 

CASI 

Cellule  d’ Analyse,  de  Simulation  et  d 'Innovation  (analysis,  simulation  and 
innovations  department  of  the  Air  Force  France) 

CDE 

Concept  Development  &  Experimentation 

CESG 

Communications-Electronics  Security  Group 

CF 

Canadian  Forces 

CFXNet 

Canadian  Forces  Experimentation  Network 

CNAD 

Conference  of  National  Armament  Directors 

COM 

Component  Object  Model  (MS  product) 

CORBA 

Common  Object  Request  Broker  Architecture 

COTS 

Commercial  Off  The  Shelf 

CROSAT 

Centre  de  Recherche  Operationnelle  et  de  Simulation  de  l  ’Armee  de  Terre 
(operational  research  and  simulation  center  of  the  Army  France) 

C3I 

Command,  Control,  Communications  and  Intelligence 
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DBMS 

Data  Base  Management  System 

DCE 

Direction  des  Centres  d’Essais  (Systems  valuation  and  Test  Directorate) 

DERA 

Defence  Evaluation  and  Research  Agency 

DGA 

Delegation  Generate  pour  I’Armement  (French  procurement  agency) 

DIF 

Data  Interchange  Format 

DIS 

Distributed  Interactive  Simulation  (IEEE  standard  1278) 

DL 

Distributed  Library 

DMSO 

Defense  Modelling  &  Simulation  Office  (US  DoD) 

DND 

Department  of  National  Defence  (of  Canada) 

DoD 

U.S.  Department  of  Defense 

DOM 

Document  Object  Model  (XML) 

DSP 

Direction  des  Systemes  de  forces  et  de  la  Prospective  (Technical  Policies  and 

Planning  Directorate  of  the  French  DGA) 

Dstl 

Defence  Science  &  Technology  Laboratory  (UK) 

DTD 

Document  Type  Definition  (XML) 

EPSA 

Equipe  de  Projet  Simulation  pour  V Acquisition 

ESPRIT 

European  Strategic  Programme  for  Research  and  Development  in  Information 
Technology 

EUCLID 

European  Co-operation  for  the  Long-term  In  Defence 

EW 

Electronic  Warfare 

FFI 

Forsvarets  forskningsinstitutt  (Norwegian  Defence  Research  Establishment) 

FEDEP 

Federation  Development  and  Execution  Process  (HLA) 

FOM 

Federation  Object  Model  (HLA) 

FR 

France 

GE 

Germany 
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HLA 

High  Level  Architecture  (US  DoD  standard  1.3,  IEEE  standard  1516) 

HLA  OMT 

HLA  Object  Model  Template 

HTML 

Hyper  Text  Marked  up  Language 

HTTP 

Hyper  Text  Transfer  Protocol 

HTTPS 

HTTP  Secure 

IDE 

Integrated  Development  Environment 

IE 

Industry  Entity 

IEEE 

Institute  of  Electrical  and  Electronic  Engineers 

IOS 

Input  Output  System 

IP 

Internet  Protocol 

IPSec 

Secure  Internet  Protocol 

IPR 

Intellectual  Property  Rights 

IT 

Information  Technology 

ITCS 

Infrastructure  Technique  Commune  de  Simulation 

JSimNet 

Joint  Simulation  Network 

J2EE 

JAVA  2  Enterprise  Edition 

MALO 

Maritime  Air  Littoral  Ops 

MA&S 

Material  Acquisition  and  Support 

MC 

NATO  Military  Committee 

MDA 

Missile  Defense  Agency  (US) 

MG 

Management  Group  ( EUCLID  RTP  11.13) 

MoD 

Ministry  of  Defence 

MS 

Microsoft 

M&S 

Modelling  &  Simulation 

M&S/SE 

Modelling  &  Simulation  and  Synthetic  Environment 
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MSAP 

Modelling  &  Simulation  Action  Plan 

MSCO 

Modelling  &  Simulation  Co-ordination  Office  (NATO) 

MSG 

Modelling  &  Simulation  Group 

MSIAC 

Modeling  and  Simulation  Information  Analysis  Center  (U.S.) 

MSMP 

Modelling  and  Simulation  Master  Plan 

VI  SR  R 

Modeling  &  Simulation  Resource  Repository 

NAC 

North- Atlantic  Council 

NATO 

North  Atlantic  Treaty  Organization 

NC3A 

NATO  Consultation,  Command  and  Control  Agency 

NBC 

Nuclear  Biologic  Chemical 

NO 

Norway 

NMSG 

NATO  Modelling  and  Simulation  Group 

NSRL 

NATO  Simulation  Resource  Library 

NSVaA 

NATO  SRL  Validation  Agent 

NSVeA 

NATO  SRL  Verification  Agent 

OMG 

Object  Management  Group 

OPERA 

Operators  Training  Distributed  Real-Time  Simulations 

OU 

Organisational  Unit  (Bundeswehr) 

PfP 

Partnership  (or  Partners)  for  Peace 

PKI 

Public  Key  Infrastructure 

POC 

Point  Of  Contact 

R&D 

Research  and  Development 

RTA 

Research  and  Technology  Agency  (NATO) 

RTB 

Research  and  Technology  Board  (NATO) 
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RTO 

Research  and  Technology  Organisation  (NATO) 

RTP 

Research  Technology  Project 

SAVE 

Synthetic  environment  Availability  and  Economy 

SAX 

Simple  API  for  XML 

SBA 

Simulation  Based  Acquisition 

SC 

Departement  “Ingenierie  des  Systemes  Complexes  ”  (“Complex  Systems 

Engineering”  Department  (SC)  of  the  DGA/  DSP) 

SCORM 

Sharable  Courseware  Object  Reference  Model 

SE 

Synthetic  Environment 

SECO 

Synthetic  Environments  Coordination  Office  (UK  and  Canada) 

SEDE 

SE  Development  Environment 

SEDEP 

SE  Development  and  Execution  Process 

SEDRIS 

SE  Data  Representation  Interchange  Specification 

SE-ATG 

Synthetic  Environment  Advanced  Technology  Group 

SGMS 

Steering  Group  for  M&S 

SISO 

Simulation  Interoperability  Standards  Organization 

SOAP 

Simple  Object  Access  Protocol 

SOM 

Simulation  Object  Model(  HLA) 

SRL 

Simulation  Resource  Library 

STANAG 

Standardisation  Agreement  (NATO) 

TAMSS 

Tactical  Aviation  Mission  Simulation  System 

TD 

Technology  Demonstrations 

TG 

Task  Group 

ToE 

Target  of  Evaluation 

TOR 

Terms  Of  Reference 

TT&S 

Thales  Training  &  Simulation 
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UK 

United  Kingdom 

UML 

Unified  Modelling  Language 

URL 

Uniform  Resource  Locator  (Internet) 

US 

United  States  of  America 

VPN 

Virtual  Private  Network 

W&A 

Verification  Validation  and  Accreditation 

WAN 

Wide  Area  Network 

XML 

extended  Marked  up  Language 

XML  DOM 

XML  Document  Object  Model 

XML  DTD 

XML  Document  Type  Definition 
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bibliographiques  completes  ainsi  que  des  resumes  des  publications  RTO  et  AGARD  figurent  dans  les  journaux  suivants  : 


Scientific  and  Technical  Aerospace  Reports  (STAR) 

STAR  peut  etre  consulte  en  ligne  au  localisateur  de 
ressources  uniformes  (URL)  suivant: 

http://www.sti.nasa.gov/Pubs/star/Star.html 
STAR  est  edite  par  CASI  dans  le  cadre  du  programme 
NASA  d’ information  scientifique  et  technique  (STI) 
STI  Program  Office,  MS  157 A 
NASA  Langley  Research  Center 
Hampton,  Virginia  23681-0001 
ETATS-UNIS 
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DISTRIBUTION  OF  UNCLASSIFIED 
RTO  PUBLICATIONS 


AGARD  &  RTO  publications  are  sometimes  available  from  the  National  Distribution  Centres  listed  below.  If  you  wish  to  receive  all  RTO  reports, 
or  just  those  relating  to  one  or  more  specific  RTO  Panels,  they  may  be  willing  to  include  you  (or  your  Organisation)  in  their  distribution. 

RTO  and  AGARD  reports  may  also  be  purchased  from  the  Sales  Agencies  listed  below. 

Requests  for  RTO  or  AGARD  documents  should  include  the  word  ‘RTO’  or  ‘AGARD’,  as  appropriate,  followed  by  the  serial  number.  Collateral 
information  such  as  title  and  publication  date  is  desirable. 

If  you  wish  to  receive  electronic  notification  of  RTO  reports  as  they  are  published,  please  visit  our  website  (www.rta.nato.int)  from  where  you  can 
register  for  this  service. 


NATIONAL  DISTRIBUTION  CENTRES 


BELGIUM 

Etat-Major  de  la  Defense 
Departement  d’ Etat-Major  Strategic 
ACOS-STRAT-STE  -  Coord.  RTO 
Quartier  Reine  Elisabeth 
Rue  d’Evere 
B-1140  Bruxelles 

CANADA 

DRDKIM2 

Knowledge  Resources  Librarian 
Defence  R&D  Canada 
Department  of  National  Defence 
305  Rideau  Street 
9th  Floor 

Ottawa,  Ontario  K1A  0K2 

CZECH  REPUBLIC 

DIC  Czech  Republic-NATO  RTO 
VTUL  a  PVO  Praha 
Mladoboleslavska  ul. 

Praha  9,  197  06 
Ceska  republika 

DENMARK 

Danish  Defence  Research 
Establishment 
Ryvangs  Alle  1 
P.O.  Box  2715 
DK-2100  Copenhagen  0 

FRANCE 
O.N.E.R.A.  (ISP) 

29,  Avenue  de  la  Division  Leclerc 
BP  72 

92322  Chatillon  Cedex 


GERMANY 

Streitkrafteamt  /  Abteilung  III 
Fachinformationszentrum  der 
Bundeswehr  (FIZBw) 
Friedrich-Ebert-Allee  34 
D-53113  Bonn 

GREECE  (Point  of  Contact) 

Defence  Industry  &  Research 
General  Directorate,  Research  Directorate 
Fakinos  Base  Camp,  S.T.G.  1020 
Holargos,  Athens 

HUNGARY 

Department  for  Scientific  Analysis 
Institute  of  Military  Technology 
Ministry  of  Defence 
H-1525  Budapest  P  O  Box  26 

ICELAND 

Director  of  Aviation 
c/o  Flugrad,  Reykjavik 

ITALY 

Centro  di  Documentazione 
Tecnico-Scientifica  della  Difesa 
Via  XX  Settembre  123 
00187  Roma 

LUXEMBOURG 

See  Belgium 

NETHERLANDS 

Royal  Netherlands  Military 
Academy  Library 
P.O.  Box  90.002 
4800  PA  Breda 


NORWAY 

Norwegian  Defence  Research 
Establishment 
Attn:  Biblioteket 
P.O.  Box  25,  NO-2007  Kjeller 

POLAND 

Armament  Policy  Department 
218  Niepodleglosci  Av. 

00-911  Warsaw 

PORTUGAL 

Estado  Maior  da  Forqa  Aerea 
SDFA  -  Centro  de  Documentaqao 
Alfragide,  P-2720  Amadora 

SPAIN 

INTA  (RTO/AGARD  Publications) 
Carretera  de  Torrejon  a  Ajalvir,  Pk.4 
28850  Torrejon  de  Ardoz  -  Madrid 

TURKEY 

Mill!  Savunma  Ba§kanligi  (MSB) 
ARGE  Dairesi  Ba§kanligi  (MSB) 
06650  Bakanliklar  -  Ankara 

UNITED  KINGDOM 

Dstl  Knowledge  Services 
Kentigern  House,  Room  2246 
65  Brown  Street 
Glasgow  G2  8EX 

UNITED  STATES 

NASA  Center  for  AeroSpace 
Information  (CASI) 

Parkway  Center,  7121  Standard  Drive 
Hanover,  MD  21076-1320 


NASA  Center  for  AeroSpace 
Information  (CASI) 

Parkway  Center 
7121  Standard  Drive 
Hanover,  MD  21076-1320 
UNITED  STATES 


SALES  AGENCIES 

The  British  Library  Document 
Supply  Centre 

Boston  Spa,  Wetherby 
West  Yorkshire  LS23  7BQ 
UNITED  KINGDOM 


Canada  Institute  for  Scientific  and 
Technical  Information  (CISTI) 

National  Research  Council 
Acquisitions 

Montreal  Road,  Building  M-55 
Ottawa  K1A  0S2,  CANADA 
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